From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2514 invoked by alias); 11 May 2011 14:46:54 -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: 29221 Received: (qmail 15892 invoked from network); 11 May 2011 14:46:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at csr.com does not designate permitted sender hosts) Date: Wed, 11 May 2011 15:09:09 +0100 From: Peter Stephenson To: Subject: Completion crash owing to bad allocation Message-ID: <20110511150909.6fd6dda0@pwslap01u.europe.root.pri> In-Reply-To: <87sjsl2wqg.fsf@ft.bewatermyfriend.org> References: <87sjsl2wqg.fsf@ft.bewatermyfriend.org> Organization: Cambridge Silicon Radio 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-Originating-IP: [10.103.11.49] X-Scanned-By: MailControl A_10_80_00 (www.mailcontrol.com) on 10.68.0.152 On Wed, 11 May 2011 15:27:35 +0200 Frank Terbeck wrote: > I'm running into a segfault, though. The git repository is located in > `/tmp/linux-2.6'. I've changed a file (fs/adfs/dir.c) slightly and I'm > doing this: > > % git add f > % git add fs/ > % git add fs/adfs/ > > And that's where the shell crashes. It's a build of today's HEAD. This seems to be another variant of the "amatches" problem. amatches is a global in the completion code that holds one version of the list of matches during completion. This is on the heap, and because it's not scoped it's virtually impossible to keep track of the point at which it becomes invalid. For extra ease of maintainance, at some point in the procedure it is deliberately set to point to a permanently allocated copy. When the crash happens we are scanning through some (possibly subtly disguised) part of amatches and examining some no longer valid memory. One way to tackle this would be to add a stack corresponding to the current heap stack, with each level having a unique (up to 32-bit integer wrap) ID that tells you if that heap variant is valid. Then when memory is allocated for use by a Cmgroup it stores the ID corresponding to the currently pushed heap at the top of the stack (with a special ID to be used if it was permanently allocated). Every time amatches is examined the code could report an error if a heap ID stored somewhere along the list doesn't correspond to one somewhere on the current heap debug stack. (Unfortunately examining amatches at the point of a popheap() won't work --- the code is lax about marking amatches as invalid, it just expects you not to access it in that case, which is part of the problem.) I won't be doing the completion code debugging, I'm fed up with days of my life disappearing into code I never seem to get any closer to understanding and have quite enough else to manage, but if someone thinks they might get round to that (understanding is optional for now, we just need to be able to track what's going on with amatches) I'd be happy to have a go at writing the tools for heap debugging. -- Peter Stephenson Software Engineer Tel: +44 (0)1223 692070 Cambridge Silicon Radio Limited Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom