From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id af18a347 for ; Fri, 27 Sep 2019 19:06:38 +0000 (UTC) Received: (qmail 9125 invoked by alias); 27 Sep 2019 19:06:26 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24296 Received: (qmail 18403 invoked by uid 1010); 27 Sep 2019 19:06:26 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-3.server.virginmedia.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25580. spamassassin: 3.4.2. Clear:RC:0(80.0.253.67):SA:0(-2.0/5.0):. Processed in 3.745369 secs); 27 Sep 2019 19:06:26 -0000 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _smtprelay.virginmedia.com designates 80.0.253.67 as permitted sender) X-Originating-IP: [86.16.88.158] X-Authenticated-User: p.w.stephenson@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=UpVNyd4B c=1 sm=1 tr=0 a=MiHCjVqLJ44lE3bxSlffFQ==:117 a=MiHCjVqLJ44lE3bxSlffFQ==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=xzqe96-Kl9KU3oM2GiwA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1569611141; bh=he7rSvTg851to6AemDdcS2eZHAwjhLew4g7nc2qWndg=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=5z1EESIDL9p4ffoS5s3W5FuarlpnM+AxOmHGAx+Fm7Pr+lPGiO86dL4sm7tJJNqqL g8UVyy21+0WMxJf92RtiHaLnKQ/RLxHlCn6CqJPVu78MkCp8+Wbk6BwtbIuCcdihYm LoKUX6XcK7kPm//xUgNhMjxHfzWqgLGuIC22oWwtMvBEOA21mNQqs14/81END04rYp /Z5VNPsoHRlUygX0xKxJf3xwrFzGj7BhOXk1lU4QnsrYomMTrSFw2AuJWL6cligg5g 4WQ3mRdDOiE7+fR8ZomzoAhXgM2XZNV5+yZDiJYrDKdlAemyxA/jZ5yuNboEegb/Bw 5T9cfdEGkMzsw== Message-ID: Subject: Re: TRAPINT doesn't work reliably From: Peter Stephenson To: zsh-users@zsh.org Cc: Dennis Schwartz Date: Fri, 27 Sep 2019 20:05:40 +0100 In-Reply-To: <7P_7qK1o03NLAWi2yO8YMPN4ErtxVF9fCDTtiPNjfRrzqKcmoysqAeR8nQ1B5DEY_uYE_Y6EBGsxysbflCAyLbm_h5qrobU4F0143UCxWW8=@protonmail.com> References: <1569314663.5531.4.camel@samsung.com> <1394985674.3969083.1569420087673@mail2.virginmedia.com> <22AgAhXQWzavJGhNA8tFbGSMGk8z3KDGGa-pICX0lWszH622z2_nnc1acuvW3OcIbqAaXM_WAGJwmQU5Oph83DGbfQEplu1t3o7F5omeC4w=@protonmail.com> <1569434163.10786.26.camel@samsung.com> <1569511539.3770.6.camel@samsung.com> <7P_7qK1o03NLAWi2yO8YMPN4ErtxVF9fCDTtiPNjfRrzqKcmoysqAeR8nQ1B5DEY_uYE_Y6EBGsxysbflCAyLbm_h5qrobU4F0143UCxWW8=@protonmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEfaSHULivKo6ht8pJsSus6r2WYScHHH4fAB7cQMUphV8KohEsB/012Sf4i1UszcQeQHJyMWoShGWja7TiNSeFJ06SoI4cfqNi6aWY6czENS5g9xm4v8 NF3scpGFduG/JJcnht5NDxUzi8DEnjcGCY2vdmMo+7NuZJ1AoAw72ioqckGDJzg7rosPUyepZxXQkAhHRGOhvkvIaeHZ0kvucW0= On Thu, 2019-09-26 at 17:10 +0000, Dennis Schwartz wrote: > I don't fully understand what you mean with "the logic where you're > defining TRAPINT," but I have the following code in my `.zshrc`: > > function TRAPINT { > VIMODE="$VIINS" > print $1 # for debug only > return $(( 128 + $1 )) > } I was just wondering if there's more structure than that around, but I think I was reading too much into what I suspect (see below) is actually irrelevant information. > I did manage to capture the bug with valgrind on `master` using the > following sequence of commands (output tidied): > > $ git checkout master > $ git checkout zsh-5.7.1 -- Config/version.mk > $ ./configure --enable-zsh-debug && make && sudo make install > $ valgrind --leak-check=full --log-file=zsh-valgrind.log /usr/local/bin/zsh > /usr/share/zsh-antigen/antigen.zsh:2134: parse error near `\n' > $ ll > TRAPINT:1: not an identifier: Thanks, this is exactly what I was asking for. Obviously TRAPINT is getting screwed up somehow. Unforunately, I think the dmaage may have been done too early for this to tell us where. > Invalid read of size 1 > at 0x4838CC2: __strlen_sse2 (vg_replace_strmem.c:462) > by 0x1B0792: dupstring (string.c:39) > by 0x19BC70: ecgetstr (parse.c:2809) > by 0x144095: addvars (exec.c:2429) > by 0x1404DB: execsimple (exec.c:1237) > by 0x140A85: execlist (exec.c:1378) > by 0x14038F: execode (exec.c:1194) > by 0x14DCB0: runshfunc (exec.c:5980) > by 0x14D2E8: doshfunc (exec.c:5830) > by 0x1AF4D1: dotrapargs (signals.c:1371) > by 0x1AFA8F: dotrap (signals.c:1487) > by 0x1AF18C: handletrap (signals.c:1202) This is saying it's trying to execute your trap. It's getting into trouble when it's trying to read in the variable assignment from the trap. Either that's the VIMODE="$VIINS" chunk that's been messed up, or it's already got confused and is guessing what's going on. I would suspect that actually the main function structure is still there, since it's otherwise quite unlikely to negotiate the exec hierarchy down to addvars(). However, it's possible it's also been erroneously freed but malloc has only grabbed the assignment part of it for reuse so far. Does removing that assignment make a difference? That's just for testing, obviously. But given the shell obviously is trying to do an assignment and that's gone awol, it might tell us something. (If, for example, the error now occurs somewhere a bit later it might indicate that indeed the entire fucntion is free and malloc() is repurposing the memory piecemeal.) > Address 0x566b948 is 0 bytes after a block of size 328 free'd > at 0x48369AB: free (vg_replace_malloc.c:530) > by 0x13D8F3: zcontext_restore_partial (context.c:108) > by 0x13DA56: zcontext_restore (context.c:119) > by 0x175A04: parse_subscript (lex.c:1697) > by 0x18B7F1: getindex (params.c:1858) > by 0x18C132: fetchvalue (params.c:2106) > by 0x1B6304: paramsubst (subst.c:2516) > by 0x1B1DB9: stringsubst (subst.c:322) > by 0x1B1108: prefork (subst.c:142) > by 0x14486C: execsubst (exec.c:2570) > by 0x1772E9: execfor (loop.c:98) > by 0x148469: execcmd_exec (exec.c:3913) > Block was alloc'd at > at 0x483577F: malloc (vg_replace_malloc.c:299) > by 0x13D5D6: zcontext_save_partial (context.c:58) > by 0x13D7E9: zcontext_save (context.c:82) > by 0x1758A7: parse_subscript (lex.c:1661) > by 0x18B7F1: getindex (params.c:1858) > by 0x18C132: fetchvalue (params.c:2106) > by 0x1B6304: paramsubst (subst.c:2516) > by 0x1B1DB9: stringsubst (subst.c:322) > by 0x1B1108: prefork (subst.c:142) > by 0x14486C: execsubst (exec.c:2570) > by 0x1772E9: execfor (loop.c:98) > by 0x148469: execcmd_exec (exec.c:3913) So this stuff is saying, when we performed a substitution we had to save and restore some memory and we used the chunk that valgrind reported the error on. In other words, it had apparently been freed somewhere else already, so malloc() just grabbed it. So I don't think the code being executed here is actually relevant to the original problem, it's just the unlucky victim that got a chunk that shouldn't have been freed in the first place. Unfortunately this doesn't tell us where that happened. But it does look like it was actually freed, i.e. the problem isn't something is stomping on memory owned by something else, it's that the memory was erroneously given back to the system. (At least, that's the simple interpretation.) Not sure quite where to go from here --- but at least we have something that's reproducible, which is quite good by the standards of memory errors. I think we'll need to add something to the code you're using that marks the memory in the TRAPINT somehow. I'll need to think what seems propitious... First simple step might be to see if the shell is indeed freeing the TRAPINT() function code at some point. That shouldn't be so hard to find out but it'll need a bit of confection. cheers pws