From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28935 invoked by alias); 18 Dec 2014 06:13:36 -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: 34002 Received: (qmail 795 invoked from network); 18 Dec 2014 06:13:35 -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 X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=Kc1larcG c=1 sm=1 tr=0 a=FT8er97JFeGWzr5TCOCO5w==:117 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=oR5dmqMzAAAA:8 a=-9mUelKeXuEA:10 a=A92cGCtB03wA:10 a=tVjDUnxbkpEw2irfLX4A:9 a=CjuIK1q_8ugA:10 From: Bart Schaefer Message-id: <141217221400.ZM13648@torch.brasslantern.com> Date: Wed, 17 Dec 2014 22:14:00 -0800 In-reply-to: Comments: In reply to Jonathan H "Re: Complex config triggering Segfault in pattern matching code." (Dec 17, 9:18am) References: <141213152840.ZM16632@torch.brasslantern.com> <141213204032.ZM16766@torch.brasslantern.com> <20141214182021.1944bbcd@pws-pc.ntlworld.com> <141215153936.ZM17826@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Complex config triggering Segfault in pattern matching code. Cc: Jonathan H MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Dec 17, 9:18am, Jonathan H wrote: } Subject: Re: Complex config triggering Segfault in pattern matching code. } } So, I ran ZSH for over 48 hours, and it finally crashed. I don't know } if it was the normal crashes I'm seeing because valgrind seems to have } rendered all of my tests useless. (Also, it gobbled up all of my RAM, } so I can't tell if that's why it crashed). } } Attached is the STDERR from "valgrind -q --trace-children=yes } --track-origins=yes" Thanks. If you do this again I think you can avoid --trace-children. } A lot of errors seem to have cropped up. Yeah, but the vast majority of them are the same error repeating. Already fixed this one: ==1705== Source and destination overlap in strcpy(0x402bd24, 0x402bd51) ==1705== at 0x4C2D766: __GI_strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1705== by 0x488CD0: stringsubst (subst.c:301) This one seems obvious: ==1705== Uninitialised value was created by a heap allocation ==1705== at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1705== by 0x45C446: zalloc (mem.c:896) ==1705== by 0x65A4781: init_keymaps (zle_keymap.c:1194) diff --git a/Src/Zle/zle_keymap.c b/Src/Zle/zle_keymap.c index be02f3a..cfef882 100644 --- a/Src/Zle/zle_keymap.c +++ b/Src/Zle/zle_keymap.c @@ -1201,7 +1201,7 @@ init_keymaps(void) { createkeymapnamtab(); default_bindings(); - keybuf = (char *)zalloc(keybufsz); + keybuf = (char *)zshcalloc(keybufsz); lastnamed = refthingy(t_undefinedkey); } This is the one that repeats a lot: ==1705== Uninitialised value was created by a heap allocation ==1705== at 0x4C2C29E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==1705== by 0x45C798: zrealloc (mem.c:938) ==1705== by 0x65B0D18: set_region_highlight (zle_refresh.c:454) It would appear that the loop at zle_refresh.c:461 needs to assign values to rhp->start_meta and rhp->end_meta at the same time that it calculates rhp->start and rhp->end. However, I'm not familiar enough with the region_highlight algorithm to be sure how to initialize those. It's possible that fixing this will fix the next one as a side-effect. Finally this one repeats a few times: ==1705== Conditional jump or move depends on uninitialised value(s) ==1705== at 0x5A04253: vfprintf (in /usr/lib/libc-2.20.so) ==1705== by 0x5A278FA: vsprintf (in /usr/lib/libc-2.20.so) ==1705== by 0x5A0ACD6: sprintf (in /usr/lib/libc-2.20.so) ==1705== by 0x65B0B66: get_region_highlight (zle_refresh.c:410) That's this: sprintf(digbuf1, "%d", rhp->start); sprintf(digbuf2, "%d", rhp->end); I'm confused about that one because I can't see where rhp->start might be coming from without getting initialized. It LOOKS like the loop in set_region_highlight() always either initializes those, or truncates the array to be no more than N_SPECIAL_HIGHLIGHTS elements long. In the latter case the loop containing those sprintf's should never make a circuit. There is a potential problem in that the loop test is just (arrsize--) which could go on infinitely if arrsize is negative when the loop begins, but there isn't enough log output for this to be an infinite loop.