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 86bfd8dd for ; Tue, 21 May 2019 21:59:13 +0000 (UTC) Received: (qmail 10071 invoked by alias); 21 May 2019 21:58: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: List-Unsubscribe: X-Seq: 44347 Received: (qmail 19873 invoked by uid 1010); 21 May 2019 21:58:54 -0000 X-Qmail-Scanner-Diagnostics: from wout1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25454. spamassassin: 3.4.2. Clear:RC:0(64.147.123.24):SA:0(-2.6/5.0):. Processed in 4.894709 secs); 21 May 2019 21:58:54 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type :content-transfer-encoding; s=fm3; bh=r3PWBvr3KIFbwiWRCGMcyl50ng Cu7IarNm/0K3ZPAqY=; b=FQ4CNkjYojqsumREAdez+L/td1TeX5leu6dGZPKRAM RFX5meNz0ORUw1TlNfbIsozku6vNngZrltJZPqpbN8HCal1T0QJNPE+rujuBsXE3 HSQIE+lBOWvluNBKcgyeO23jDS0K3W0A4QszqG9Na3+N0VZdw79svb6Z03sJ/+8X Vnu9GJSs50po7DA8/FA9n99zMIhikJBMXchfy1+XlUgJLuLGQowm15tpxzmQoS9q FG7IlqQb/JoRozDzuKIg12i975ZdcISoPlSyLrxqFZhsodgZNIuPVHUzMH0aiFDw ZQ3V7frlnwH6UonT49mdNxwLnZDw2BiUgpu303HnBULQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=r3PWBvr3KIFbwiWRCGMcyl50ngCu7IarNm/0K3ZPA qY=; b=cPBe712DVj0JKHWHo7CgN8emwxJBMCEl9MoScbA/m9E6w/4GudymrlhRI N61yFkRzUI20dF7K1+fg18pqgJespxgvZDXiiPLvhZyJ8bWdPs7iEf9IfIcQ7a0Y 8dxHcwaautfti1U5uv9h0A0msBVTrSjHn6K9pc+3IGgK4oO84R6jdqSgrOSlmggd Dwdbv4BfUZzoAIv3EkZ8ZJPDXE2nsNp68BDyV8iEX00bLEXv5+PL0HZupG2/jHVi sAB0swMVdnhJ8IiMHHvBsgkmUyvyALxRHKRQHoIAXmitF7YR0q8s0U/4kSQQfvR5 wA2K82DDlHdsQB0F6+AUjpYlXjzSQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudduuddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfffgr nhhivghlucfuhhgrhhgrfhdfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmh gvqeenucffohhmrghinheprghprggthhgvrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvgenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-550-g29afa21-fmstable-20190520v1 Mime-Version: 1.0 Message-Id: <90e15b90-14bb-4ef0-9aef-cc15c0fa0935@www.fastmail.com> In-Reply-To: <92606-1558385755.382793@sll5.5oha.0as1> References: <92606-1558385755.382793@sll5.5oha.0as1> Date: Tue, 21 May 2019 21:58:11 +0000 From: "Daniel Shahaf" To: "Oliver Kiddle" , "Wesley Schwengle" Cc: zsh-workers@zsh.org Subject: Re: segfault via completion menu Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Oliver Kiddle wrote on Mon, 20 May 2019 20:57 +00:00: > Backing that out on top of master appears to fix the issue. As it was = an > optimisation, that might be an option. From reading comments in mem.c,= > it's not especially clear to me what newheaps/oldheaps do. There's onl= y > the one other use. It's not too clear to me either. The defining property of a heap, IIUC, is that freeheap() and popheap() release all heap-allocated memory allocated since the last pushheap(). In this respect they're analogous to APR pools, which I'm familiar with=C2=B9. Then, what NEWHEAPS() seems to do is put away the entire stack of heaps, create a new stack of heaps, and then OLDHEAPS() frees the entire new stack of heaps and reverts to the old one. How is this better than simply doing pushheap() and popheap()? =20 - Code between NEWHEAPS() and OLDHEAPS() doesn't have to be careful to match pushheap() and popheap() calls exactly, because OLDHEAPS() will clean up everything anyway. =20 - Anything allocated on heap between NEWHEAPS() and OLDHEAPS() becomes invalid once OLDHEAPS() is called. - There might be some considerations about maximum depth of the stack or= total number of bytes allocated by heaps in a single stack? - (Anything else?) HTH, Daniel =C2=B9 https://subversion.apache.org/docs/community-guide/conventions.ht= ml#apr-pools pushheap() =E2=89=88 { p =3D apr_pool_create(p); } popheap() =E2=89=88 { tmp =3D p->parent; apr_pool_destroy(p); p =3D tm= p; }