>>>> "Michael" == Michael Sperber
<sperber(a)informatik.uni-tuebingen.de> writes:
>>>> "APA" == Adrian Aichner <adrian(a)xemacs.org> writes:
>>>> "davep" == David A Panariti
<davep.xemacs(a)meduseld.net> writes:
APA> Hi David,
APA> please use M-x efs-report-bug to make sure to get the EFS developers
APA> attention.
Michael> Except it's not an EFS bug if XEmacs crashes (in the process
Michael> code). I'm sort of clueless: I run under FreeBSD myself, and
Michael> I've never seen this bug.
I've tracked down at least one facet of the problem.
It is not an EFS problem, it's a pty problem that EFS triggers due to its use
of ptys.
The problem is that, occasionally, an opened pty does NOT
retain its pty-ness after a fork.
Here is an excerpt from process-unix.c showing where the problem occurs:
process-unix.c:894
set_descriptor_non_blocking (inchannel);
set_descriptor_non_blocking (outchannel);
/* Record this as an active process, with its channels.
As a result, child_setup will close Emacs's side of the pipes. */
init_process_io_handles (p, (void*)inchannel, (void*)outchannel,
pty_flag ? STREAM_PTY_FLUSHING : 0);
/* Record the tty descriptor used in the subprocess. */
UNIX_DATA(p)->subtty = forkin;
fprintf(stderr, "2: isatty(forkin): %d\n", isatty(forkin));
{
#if !defined(CYGWIN)
#warning "!CYGWIN"
/* child_setup must clobber environ on systems with true vfork.
Protect it from permanent change. */
char **save_environ = environ;
#endif
pid = fork ();
if (pid == 0)
{
/**** Now we're in the child process ****/
int xforkin = forkin;
int xforkout = forkout;
fprintf(stderr, "3: isatty(forkin): %d\n", isatty(forkin));
I've actually seen this happening.
Here're the prints:
2: isatty(forkin): 1
3: isatty(forkin): 0
If I close and reopen the pty, it seems to fix things, but it smells like a
Paclid hack: ``It needs this to make it go.''
And, of course, now that I've added even more debugging code, the problem is
no longer occurring. But I did see the pty-ness change and running the hack
prevented the core dump.
I don't know if xemacs is using FreeBSD's ptys incorrectly, or
if there is a bug in FreeBSD's pty or fork code.
I'm running: FreeBSD
baloo.meduseld.net 4.8-RELEASE FreeBSD 4.8-RELEASE #1
and
XEmacs 21.4 (patch 13) "Rational FORTRAN" [Lucid] (i386-unknown-freebsd4.8,
Mule) of Thu Jul 17 2003 on
baloo.meduseld.net
Anyone have any ideas???
thanks,
davep
--
Decision maker, n.:
The person in your office who was unable to form a task force
before the music stopped.