From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12839 invoked by alias); 18 Jan 2014 21:34:11 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 32284 Received: (qmail 5631 invoked from network); 18 Jan 2014 21:34:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140118133407.ZM10286@torch.brasslantern.com> Date: Sat, 18 Jan 2014 13:34:07 -0800 In-reply-to: <87sism8ie6.fsf@ft.bewatermyfriend.org> Comments: In reply to Frank Terbeck "Re: Bug with long multiline strings?" (Jan 17, 9:24pm) References: <87vcdzq4ke.fsf@ft.bewatermyfriend.org> <20121024171023.313995d7@pwslap01u.europe.root.pri> <20121025095936.621c7717@pws-pc.ntlworld.com> <87bofqq54z.fsf@ft.bewatermyfriend.org> <87sism8ie6.fsf@ft.bewatermyfriend.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Bug with long multiline strings? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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.