From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16082 invoked by alias); 30 Sep 2015 21:19:44 -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: 36727 Received: (qmail 20668 invoked from network); 30 Sep 2015 21:19:42 -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-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=WsL6/WEY2QaIfkV3FQ1ffot6geUX4AOTOIrxmAdc1ZI=; b=ONc2vMsGvcpFunY8obkyDhEEYRIIzHQCgIPhXegTM5+SwOFfn1r8JEGx4DdwfXXumM u24P7cXmpE/rCKtKcsJQkv0Uu7XvQXuhCV7o7w4qoE4vJmpUTX+on/tVk1LTwmEck1UR ++MUQBBGJlqA8NyG2QqXYHm5rKvqRDVoEQkDJgUwbIOWtrXVjjcMGiRrbXnOSeS51ahj uddyWe0pT7kD7cjKC92yNrA5sq1AZdok8420Y5dyqWEu57fsalF0gengOSRUBRN+gsnU 2C/wJmX7MDumjvxQhtNF0Mpyi9DyJ3I3pIusI35Ok+Ndx7VDAbRCDa1B5xCRu4J5uw3z Z4dQ== X-Gm-Message-State: ALoCoQmwCTR+aVhoy1mX0m0qTEM5JTab6rDejGQCRyqdfe52/+p3RgG9Qo7CZsMKYXQvmoS6SOgi X-Received: by 10.60.79.226 with SMTP id m2mr4004177oex.20.1443647979511; Wed, 30 Sep 2015 14:19:39 -0700 (PDT) From: Bart Schaefer Message-Id: <150930141937.ZM22962@torch.brasslantern.com> Date: Wed, 30 Sep 2015 14:19:37 -0700 In-Reply-To: <20150930150433.21f70e13@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Substitution ${...///} slows down when certain UTF character occurs" (Sep 30, 3:04pm) 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> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Substitution ${...///} slows down when certain UTF character occurs MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 30, 3:04pm, Peter Stephenson wrote: } Subject: Re: Substitution ${...///} slows down when certain UTF character } } In some complex git completion --- reproducible only in one set up --- } the heap allocation is apparently going out of bounds. Yet I've checked } and nothing seems able to happen that can affect this. If I add } debugging, the same pointer is reported as returned from zhalloc() that } is later claimed to be out of bounds. Yet with more debugging there's } no popheap() or switch_heap() happening, as by eye there can't be. I'm } a bit stuck; how can a piece of memory returned by zhalloc() suddenly go } invalid? } } valgrind agrees with gdb but doesn't give any more help. Did you --enable-zsh-heap-debug and --enable-zsh-valgrind ? I always forget at least the latter of those ... } Maybe we're just running out of memory after all? That seems really unlikely, unless the explicit zalloc version shows a similar issue. But I suppose if the heap is never popped it might be possible to run out of memory on a deep recursive glob. Perhaps a call to freeheap() is needed somewhere prior to the popheap()? Or maybe there *is* a freeheap() happening where it isn't any longer safe to do so -- did you check for that? Even if out of memory, I wouldn't expect an existing pointer to go bad. You'd just fail to get a new one. And heaps are mmap()d if possible so in that case you'd have to be out of address space, not just out of memory?