Re: TR : Re : [BUG] Crash due to malloc call in signal handler

[Peter Stephenson <p.stephenson@samsung.com>]

On Fri, 2019-12-13 at 18:09 +0100, Antoine C. wrote:
> (and now zsh mail server is returning back all my mails 
> to the list (????), so I am replying directly to you...)

Looks like it got there, if I'm interpreting my email correctly, so I'll
abbreviate for the response.

> So Peter what I understand from your mails is that malloc
> functions are called from signal handler on purpose, but 
> only at the time you think is right, so even if it is 
> forbidden, it should work... Well, it does not. There is
> a backtrace at the end of the mail showing it clearly, but
> we can dive into the details to understand what is happening.

This trace is much more useful than the previous one, which
I think was too late....

The readoutput function is indeed unqueueing signals, and also has some
memory managament.  It's clear from the code there's an attempt to fix
the issues, but there's obviously something left.

If you're using the current git source, exec.c line 4673 has a call to
fgetc(), which is indeed outside where signals are queued.  Are you able
to confirm this is correct?

I think the intention here is to make sure we're not blocking for a long
time in this function, but if fgetc() is doing memory allocation we're
going to have to put that in the signal blocking.  However, if the input
itself blocks in fgetc() that's going to be a problem.  The fix might be
not to fdopen() the input file, but just read into a buffer with
read().

Here's the relevant chunk, though on the last line, and the fact there's
a memory allocation with a signal handle on top of it, are really
important.

#7  0x00005555556008d5 in zhandler (sig=17) at signals.c:648
#8  <signal handler called>
#9  0x00007ffff7314a55 in _int_malloc (av=av@entry=0x7ffff7643bc0 <main_arena>, bytes=bytes@entry=4145) at malloc.c:4149
#10 0x00007ffff7315be6 in __GI___libc_malloc (bytes=4145) at malloc.c:3088
#11 0x00007ffff7318335 in mallochook (size=4096, caller=0x7ffff72ff459 <__GI__IO_file_doallocate+121>) at mcheck.c:311
#12 0x00007ffff7315d4a in __GI___libc_malloc (bytes=bytes@entry=4096) at malloc.c:3057
#13 0x00007ffff72ff459 in __GI__IO_file_doallocate (fp=0x55555589aba0) at filedoalloc.c:101
#14 0x00007ffff730e379 in __GI__IO_doallocbuf (fp=fp@entry=0x55555589aba0) at genops.c:347
#15 0x00007ffff730d26c in _IO_new_file_underflow (fp=0x55555589aba0) at fileops.c:490
#16 0x00007ffff730e3f2 in __GI__IO_default_uflow (fp=0x55555589aba0) at genops.c:362
#17 0x00005555555980bc in readoutput (in=12, qt=1, readerror=0x0) at exec.c:4673

pws