From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26766 invoked by alias); 18 Sep 2013 03:06:48 -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: 31734 Received: (qmail 24969 invoked from network); 18 Sep 2013 03:06:42 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130917200551.ZM14080@torch.brasslantern.com> Date: Tue, 17 Sep 2013 20:05:51 -0700 In-reply-to: <20130917200546.6094eb98@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: Segfault on "task " with zsh 5.0.2 (minimal dataset to reproduce the issue found)" (Sep 17, 8:05pm) References: <20130913122426.GA19439@sym.noone.org> <20130916171841.GG3544@sym.noone.org> <20130917095657.4cb4ccbf@pwslap01u.europe.root.pri> <20130917161058.GJ3544@sym.noone.org> <20130917163509.GK3544@sym.noone.org> <20130917200546.6094eb98@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Segfault on "task " with zsh 5.0.2 (minimal dataset to reproduce the issue found) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 17, 8:05pm, Peter Stephenson wrote: } } Well, completion's very slow, suggesting something fairly heavy is } happening, but it hasn't crashed yet. I don't suppose it's memory } exhaustion? The shell's not very robust about that. The stack trace from the very first message in the thread indicates it dies dereferencing the descr field of a Cvdef structure from the cvdef_cache array. The trace doesn't show the call to zsfree so it is the Cvdef pointer itself that is bad, not the struct contents. The valgrind output confirms this, which seems to indicate that the cvdef_cache array is being scribbled on ... but that's static memory, so it would have to be from overflowing some adjacent static storage (?) and 0x100000001 looks suspicious as a value that's repeatably so scribbled. A watchpoint on cvdef_cache[0] might shed some light.