Re: Crash while testing a completion: trap handlers and malloc?

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sep 21, 11:05am, Sven Wischnowsky wrote:
} Subject: Re: Crash while testing a completion: trap handlers and malloc?
}
} Bart Schaefer wrote:
} 
} > got a core dump with the following huge stack trace.  Note that the SIGALRM
} > trap handler is being [...] called during zalloc().
} 
} I think the library should take care of this, but maybe if we move the 
} (|un)queue_signals() calls from our malloc down into zalloc() and friends?

This was discussed a very long time ago (when the zsh memory routines were
first introduced) and rejected by Zoltan on the grounds that it made it too
slow to call malloc().  There are a couple mentions of this in the mailing
list archives (e.g. zsh-workers/291 (yes, two hundred ninety one) and 1441)
but the real discussion was on the old, pre-archives zsh-list.

Given the recent changes that reduce the number of allocation calls that
zsh makes in normal operation, and given that zhalloc() already contains
queue_signals() calls, I wouldn't object to queuing signals around every
possible call to malloc().

Note, however, that the calls in zhalloc() are needed independently, to
protect zsh's own internal heap pointers from being garbled by a signal
handler.  So if we added queue_signals() calls lower down, we'd have to
be sure that they "nest" properly with the ones in zhalloc(), so that an
unqueue_signals() at a lower level doesn't prematurely allow signals into
zhalloc().  (Remember the similar problems with child_block() that had to
be worked around earlier in the 3.1.5-pws-* cycle?)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com