Re: Wasn't this supposed to be fixed?

Re: Wasn't this supposed to be fixed?

[Jan D.]

David Kastrup wrote:

> I can't really swear to it, but I thought that I had the most recent
> stuff installed with regard to the malloc hangs.
> 
> Backtrace (a bit different than last time)

Yes, this is very different from the last bug, thanks for the trace.  I Cc:d 
emacs-devel as I am not quite sure how this should work.  What you have here
is the signal handler is invoked because there is an expose event.  But during 
the handling of that expose event, another signal arrives, SIGCHLD, because 
some subprocess died.  So we have two signal handlers invoked at the same time, 
and after that things go bad, since both handlers tries to use malloc/free.

So the question to emacs-devel is if BLOCK_INPUT should block all signals
and this handler was just forgotten, or should it just block the input (SIGIO) 
signal, and this case must be dealt with in some other fashion?  Note that 
XTread_socket does invoke BLOCK_INPUT on entry and UNBLOCK on exit, so the 
first signal handler invoked thinks it is safe from signals.

Thanks,

	Jan D.

> (gdb) bt
> #0  0xffffe002 in ?? ()
> #1  0x0815566f in emacs_blocked_malloc (size=44)
>     at /home/tmp/emacs/src/alloc.c:974
> #2  0x42073305 in malloc () from /lib/tls/libc.so.6
> #3  0x42024890 in _nl_make_l10nflist () from /lib/tls/libc.so.6
> #4  0x42022c1c in _nl_find_domain () from /lib/tls/libc.so.6
> #5  0x4202205d in __dcigettext () from /lib/tls/libc.so.6
> #6  0x42021bf5 in dcgettext () from /lib/tls/libc.so.6
> #7  0x4207aa3e in strsignal () from /lib/tls/libc.so.6
> #8  0x0819c0fc in sigchld_handler (signo=17)
>     at /home/tmp/emacs/src/process.c:6216
> #9  <signal handler called>


> #10 0x42074455 in _int_free () from /lib/tls/libc.so.6
> #11 0x420734d6 in free () from /lib/tls/libc.so.6
> #12 0x0815557e in emacs_blocked_free (ptr=0x87ac2b0)

> #52 0x400fa200 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0
> #53 0x080efa74 in XTread_socket (sd=0, bufp=0xbffd00ec, numchars=4096,
>     expected=1) at /home/tmp/emacs/src/xterm.c:7174
> #54 0x08118b32 in read_avail_input (expected=1)
>     at /home/tmp/emacs/src/keyboard.c:6621
> ---Type <return> to continue, or q <return> to quit---
> #55 0x08118d02 in input_available_signal (signo=29)
>     at /home/tmp/emacs/src/keyboard.c:6779
> #56 <signal handler called>

Re: Wasn't this supposed to be fixed?

[Richard Stallman]

The way this is supposed to work is that sigchld_handler is not
supposed to call malloc.  However, it was changed to call
strsignal, and that calls malloc.

I think the best fix is to bring it back to the original design and
move the call to strsignal out of the signal handler.  Instead, it can
set another variable; Fcall_process can check that variable and call
strsignal.

Would you like to implement this?

Re: Wasn't this supposed to be fixed?

[Jan D.]

> The way this is supposed to work is that sigchld_handler is not
> supposed to call malloc.  However, it was changed to call
> strsignal, and that calls malloc.
>
> I think the best fix is to bring it back to the original design and
> move the call to strsignal out of the signal handler.  Instead, it can
> set another variable; Fcall_process can check that variable and call
> strsignal.
>
> Would you like to implement this?

I'll fix it.

	Jan D.

Re: Wasn't this supposed to be fixed?

[Jan D.]

Richard Stallman wrote:
> The way this is supposed to work is that sigchld_handler is not
> supposed to call malloc.  However, it was changed to call
> strsignal, and that calls malloc.
> 
> I think the best fix is to bring it back to the original design and
> move the call to strsignal out of the signal handler.  Instead, it can
> set another variable; Fcall_process can check that variable and call
> strsignal.
> 
> Would you like to implement this?

Now checked in, please test.

Thanks,

	Jan D.