In XEmacs 21.2 (beta32) "Kastor & Polydeukes" [Lucid] (sparc-sun-solaris2.7) of Fri Mar 31 2000 on rhea configured using `configure --prefix=/export/users/hamishm/xemacs --site-prefixes=/export/users/hamishm/gnome:/export/users/hamishm --pdump' CVS updated at 9:10am EST March 31 2000. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I recently started playing around with eshell by John Wiegley (http://www.emacs.org/~johnw/eshell.html) I'm using version 2.2.1, with a couple of bug fixes for my non-MULE XEmacs: (defun process-coding-system (blug) (cons nil nil)) (defun coding-system-eol-type (coding) nil) I discovered that when attempting to do some piping in eshell (e.g. "ls | head"), my XEmacs was dying. I started to do some investigation. I got the following backtrace: #0 assert_failed (file=0x22bda8 "lstream.h", line=33, expr=0x22bdb8 "RECORD_TYPEP (obj, lrecord_type_lstream)") at emacs.c:2748 #1 0xdace4 in unix_send_process (proc=5188096, lstream=0x37fc00) at lstream.h:33 #2 0x167b38 in send_process (proc=5188096, relocatable=5573876, nonrelocatable=0x0, start=0, len=315) at process.c:988 #3 0x16a2a8 in Fprocess_send_string (process=5188096, string=5573876, from=-24697440, to=-24697440) at process.c:1118 This backtrace is actually somewhat misleading, since the lstream passed in to unix_send_process is perfectly valid. The lstream that is being barfed on in p->pipe_outstream (where p is the process structure referred to by Lisp_Object argument proc. It looks like the problem is that "head" exits before reading all its input (pretty normal for "head", I think). It turns out that the following loop (lines 1148-1158 of process-unix.c) is the culprit: while (Lstream_was_blocked_p (XLSTREAM (p->pipe_outstream))) { /* Buffer is full. Wait, accepting input; that may allow the program to finish doing output and read more. */ Faccept_process_output (Qnil, make_int (1), Qnil); old_sigpipe = (SIGTYPE (*) (int)) signal (SIGPIPE, send_process_trap); Lstream_flush (XLSTREAM (p->pipe_outstream)); signal (SIGPIPE, old_sigpipe); } The following backtrace shows p->pipe_outstream being set to Qnil as part of the above call to Faccept_process_output: #0 deactivate_process (proc=5698048) at process.c:1865 #1 0x169ed8 in remove_process (proc=5698048) at process.c:1878 #2 0x16802c in status_notify () at process.c:1408 #3 0xe0ad4 in execute_internal_event (event=5698048) at event-stream.c:3045 #4 0xdfd84 in Faccept_process_output (process=-24697440, timeout_secs=165, timeout_msecs=3406848) at event-stream.c:2641 #5 0xdaca4 in unix_send_process (proc=5698048, lstream=0x37f600) at process-unix.c:1175 #6 0x167b38 in send_process (proc=5698048, relocatable=5985204, nonrelocatable=0x0, start=0, len=315) at process.c:988 Subsequently, at line 1156, Lstream_flush is called, using XLSTREAM(p->pipe_outstream) as an argument. At this point, p->p->pipe_outstream is no longer an lstream, but is nil; the assertion fails, BOOM. I'm not sure what the correct fix is here. Regards, Hamish.