Re: Bug with long multiline strings?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 17,  9:24pm, Frank Terbeck wrote:
}
} Again, here's what triggers the bug:
} 
} [snip]
} zsh% foo='asdf
} quote> asdf
} quote> asdf
} quote> asdf
} quote> asdf
} quote> asfd
} quote> asdf
} quote> asdf
} quote> asdf
} quote> asdf
} quote> asdf
} quote> asdf
} quote> asdf
}  mem.c:604: BUG: hrealloc() called for non-heap memory.
} [1]    2554 segmentation fault (core dumped)  zsh
} [snap]
} 
} >From "zsh -f", I can trigger the bug with one of the following
} two snippets:
} 
} #+BEGIN_SRC shell-script
} zle-line-init() {
}     for w in a; do : $w; done
} }
} 
} zle -N zle-line-init
} 
} I tried to minimise the code further, but I couldn't trigger it without
} the loop within the function. But it's enough to define one of the two;
} although defining both will trigger it as well.

Took me a few passes, but I traced the bug to this:

#0  freeheap () at ../../zsh-5.0/Src/mem.c:382
#1  0x0808bd23 in execfor (state=0xbfeb4a20, do_exec=0)
    at ../../zsh-5.0/Src/loop.c:188
#2  0x08067e53 in execcmd (state=0xbfeb4a20, input=0, output=0, how=18, 
    last1=2) at ../../zsh-5.0/Src/exec.c:3232
#3  0x08063b8a in execpline2 (state=0xbfeb4a20, pcode=131, how=18, input=0, 
    output=0, last1=0) at ../../zsh-5.0/Src/exec.c:1691
#4  0x08062f2f in execpline (state=0xbfeb4a20, slcode=12290, how=18, last1=0)
    at ../../zsh-5.0/Src/exec.c:1478
#5  0x08062807 in execlist (state=0xbfeb4a20, dont_change_job=1, exiting=0)
    at ../../zsh-5.0/Src/exec.c:1261
#6  0x0806225a in execode (p=0x91a75f8, dont_change_job=1, exiting=0, 
    context=0x8138102 "shfunc") at ../../zsh-5.0/Src/exec.c:1070
#7  0x0806b22a in runshfunc (prog=0x91a75f8, wrap=0x0, 
    name=0xb7d82f60 "zle-line-init") at ../../zsh-5.0/Src/exec.c:4865
#8  0x0806af66 in doshfunc (shfunc=0x919fa58, doshargs=0x0, noreturnval=1)
    at ../../zsh-5.0/Src/exec.c:4756
#9  0x0811a256 in execzlefunc (func=0x919fca8, args=0xbfeb4d60, set_bindk=1)
    at ../../../zsh-5.0/Src/Zle/zle_main.c:1390


That freeheap() is discarding a heap that is still in use.  I'm not sure
why the mem.c line number shows up as the end of the function, this is a
gdb watchpoint so there must be some kind of optimization involved; the
actual event is that heaps = NULL is happening at line 380 even though
the accumlated multi-line buffer is still live in the heap.

The freeheap() is there so that we don't grow memory continuously over
the course of a long loop, but apparently in some cases it has a bad
interaction with the surrounding pushheap/popheap.  If I simply skip
the heaps = NULL in freeheap, popheap crashes, so something subtle is
going on.

I'm out of time to chase this for now, maybe somebody else can pick it up
before I get back to it.