From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22085 invoked by alias); 1 Oct 2015 14:28:32 -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: 36734 Received: (qmail 23240 invoked from network); 1 Oct 2015 14:28:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f794b6d000001495-f9-560d4309a333 Date: Thu, 01 Oct 2015 15:28:23 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Heap corruption [the thread formerly known as substitution] Message-id: <20151001152823.19512ecd@pwslap01u.europe.root.pri> In-reply-to: <20151001094140.413b5401@pwslap01u.europe.root.pri> References: <150926134410.ZM17546@torch.brasslantern.com> <150927091121.ZM25721@torch.brasslantern.com> <20150928095142.385a33eb@pwslap01u.europe.root.pri> <20150928202312.6679b38e@ntlworld.com> <20150929094436.32b62692@pwslap01u.europe.root.pri> <20150929193726.38235c76@ntlworld.com> <150929122356.ZM30421@torch.brasslantern.com> <20150930095950.6c9c583b@pwslap01u.europe.root.pri> <20150930150433.21f70e13@pwslap01u.europe.root.pri> <150930141937.ZM22962@torch.brasslantern.com> <20151001094140.413b5401@pwslap01u.europe.root.pri> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsVy+t/xq7qczrxhBrda9SwONj9kcmD0WHXw A1MAYxSXTUpqTmZZapG+XQJXxvSHu9kKTnFWrLr7jqWB8RJ7FyMnh4SAicTd3/cYIWwxiQv3 1rN1MXJxCAksZZT419jOBOHMYJJovd/ACuFsZZTo72oGaufgYBFQlXj3oAqkm03AUGLqptlg k0QExCXOrj3PAmILC7hIbF99FMzmFbCXuPtyMTOIzSngINFyei4jxMydrBLbJ28BS/AL6Etc /fuJCeIke4mZV84wQjQLSvyYfA9sELOAlsTmbU2sELa8xOY1b8F6hQTUJW7c3c0+gVFoFpKW WUhaZiFpWcDIvIpRNLU0uaA4KT3XSK84Mbe4NC9dLzk/dxMjJGy/7mBceszqEKMAB6MSD69E Ok+YEGtiWXFl7iFGCQ5mJRHe7za8YUK8KYmVValF+fFFpTmpxYcYpTlYlMR5Z+56HyIkkJ5Y kpqdmlqQWgSTZeLglGpg3Mcro/2ikNX3TGX6ZGutyU/S5PtVdX6tNarSZAtr9OlyPiBRse5R sO6N5RsXX0lZOFFnevIM6TrBExxTn808EutqvGbqnFfPb+bvVTYOlvtQYPnSxM/kjrXzc2fj 4FmsUxdv+v2svdxA6OCztzPFvso9XvZv7v5jU1V5Tjk/q2JiezFn+p6/SUosxRmJhlrMRcWJ ADBxo2NXAgAA On Thu, 1 Oct 2015 09:41:40 +0100 Peter Stephenson wrote: > > On Sep 30, 3:04pm, Peter Stephenson wrote: > > } In some complex git completion --- reproducible only in one set up --- > > } the heap allocation is apparently going out of bounds. Some progress. I've copied some heap info at the point the allocation takes place --- this is a bespoke debug structure but it's pointing to standard shell info: (gdb) p copied_heap_info $1 = {heap = 0x2b98ac551000, arena = 0x2b98ac551028, size = 16344, alloc = 0x2b98ac555000} (gdb) p *copied_heap_info.heap $2 = {next = 0x0, size = 16384, used = 16344, sp = 0x27a13b0, heap_id = 38650} That "alloc" is what gdb, valgrind and the OS itself agree is out of bounds. Sure enough, the sums say the heap finishes at 0x2b98ac555000, heap + 16384 or equivalently arena + 16344. Likely this is the last heap allocated. All the addresses look consistent, no obvious of corruption unless it's being very sneaky, so this is starting to look like a real heap problem when you happen to get a chance address clash (remember this is a 64-bit system, if that's relevant). Bart, any immediate reaction before I dig further? pws