On Sun, Jan 20, 2013 at 8:58 PM, Rob Browning <r...@defaultvalue.org> wrote: > Christopher Wellons <mosquito...@gmail.com> writes: > >> I don't see an emacs24-dbg yet, so here's a backtrace of a non-debian >> build. > >> Program received signal SIGSEGV, Segmentation fault. >> create_pty (process=143565397) at process.c:1996 >> 1996 FD_SET (inchannel, &input_wait_mask); >> (gdb) bt >> #0 create_pty (process=143565397) at process.c:1996 > > Wonder what the arguments to FD_SET are()...
After poking more with the debugger on both the non-segfaulting and
segfaulting system I finally found the bug. Both inchannel and
outchannel are still -1 at the FD_SET, from being set at
process.c:1940. So the root bug -- pipe processes are broken -- occurs
in both systems, it's just not triggering a segfault on one of them.
For example, try this on your system,
(let* ((process-connection-type nil)
(process (start-process "pipe" nil nil))
(output nil))
(set-process-filter process (lambda (p v) (setq output v)))
(run-at-time 2 nil #'process-send-string process "hello")
(accept-process-output process)
(delete-process process)
output)
If it doesn't immediately segfault, what *should* happen is a 2-second
freeze (a la run-at-time), then "hello" is returned. However, this
will block forever because the pipe was never actually created. Set
process-connection-type to t instead of nil, which tells it to use a
pty instead of a pipe, and it works as expected.
In create_process(), at process.c:1594 there's an else clause that
sets inchannel and outchannel to a pipe if they haven't yet been
set. This pipe-instantiation is missing in create_pty(), allowing the
-1 to fall through rather than create a pipe.
I stumbled through a fix (attached), copying part of the else clause
from create_process(). This patch makes the elisp code above work
properly and fixes the segfaulting on my other system.
pipe-fix.patch
Description: Binary data
