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

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

On Fri, 2019-12-13 at 11:19 +0100, Roman Perepelitsa wrote:
> On Fri, Dec 13, 2019 at 11:17 AM Peter Stephenson
> <p.stephenson@samsung.com> wrote:
> > 
> > 
> > On Fri, 2019-12-13 at 10:45 +0100, Roman Perepelitsa wrote:
> > > 
> > > On Fri, Dec 13, 2019 at 10:40 AM Peter Stephenson
> > > <p.stephenson@samsung.com> wrote:
> > > > 
> > > > 
> > > > The main shell is suspended, waiting for a child to finish, so the fact
> > > > it's in the signal handler isn't saying anything.
> > > > 
> > > > From the look of it, some memory corruption must already have occurred
> > > > at this point to get the malloc to fail.
> > > malloc is not async signal safe. It's illegal to call it from a signal
> > > handler. I'm not saying this is what's causing a crash.
> > In zsh, this is handled by queuing interrupts and only allowing them to
> > run in a few places in the code.  Obviously, waiting for a child to
> > exit is one of those places.
> The stack trace shows malloc being called zhandler. zhandler is a
> signal handler. What am I missing?

You're not missing anything there, that's how it works.

Interrupts are queued so they don't normally go off.

In certain places they are allowed to take place; one of these is when
we are sitting waiting for a child to exit.

At this point the signal handler will then run.

Thus the signal handler is supposed not to be running when any memory
management is taking place underneath.  So it's not asynchronous
with respect to code actually running in the main shell (despite being
run from a signal handler which can formally occur anywhere, but
we make sure it doesn't).

Of course, there's the possibility of bugs in this, but the stack in
this case doesn't show evidence of that at the point in question.

You'll find long discussions of this in the mail archive going back
some years.

pws