Re: zsh malloc/heap corruption

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Sep 27, 2025 at 2:56 AM Anthony Heading <ajrh@xxxxxxxx> wrote:
>
> Thanks for looking at it so quickly.   OS and version as mentioned in orig message:
>
> > Running on Linux 6.12.38+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.38-1 (2025-07-16) x86_64 GNU/Linux,  using both Debian's installed zsh:amd64 5.9-8+b14, but also current git master in both release and debug build.    (git 3cd363c8804)

Sorry, glossed over that somehow.

> > On the other hand, it doesn't DO anything either, except hang with 5
> > zsh processes and one grep still running.
>
> So that 'wait' isn't helpful, is it?  Suggest to just remove it,  and then run with more iterations.

I'm still curious what this is intended to do, because at least part
of the time it just hangs on opening the fifo (according to strace)
and part of the time it just finishes.

One time I got one crash event out of some thousands of threads before
the hang ... stack trace (skipping over the malloc internals):

#9  0x00005b934b808403 in zalloc (size=8) at mem.c:966
#10 0x00005b934b7f5d0a in addbgstatus (pid=127296, status=0) at jobs.c:2376
#11 0x00005b934b7f0fba in update_bg_job (jn=0x5b9355994f80, pid=127296,
    status=0) at jobs.c:690
#12 0x00005b934b83f6bd in wait_for_processes () at signals.c:375
#13 0x00005b934b83fcac in zhandler (sig=17) at signals.c:431
#14 <signal handler called>
...
#24 0x00005b934b878e19 in zcond_regex_match (a=0x7987fd7e6760, id=0)
    at regex.c:92
#25 0x00005b934b7b7d7c in evalcond (state=0x7fff89425740, fromtest=0x0)
    at cond.c:158
#26 0x00005b934b7ca480 in execcond (state=0x7fff89425740, do_exec=0)
    at exec.c:5242
#27 0x00005b934b7bd4e1 in execsimple (state=0x7fff89425740) at exec.c:1337

So it looks like there's a malloc re-entry when a background child
exit is handled during the
   while [[ $trace_buffer == *$'\n'* ]]; do
condition.  Bug in the zsh/regex module.