Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: segfault via completion menu
- X-seq: zsh-workers 44347
- From: "Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>
- To: "Oliver Kiddle" <okiddle@xxxxxxxxxxx>, "Wesley Schwengle" <wesley@xxxxxxxxxx>
- Subject: Re: segfault via completion menu
- Date: Tue, 21 May 2019 21:58:11 +0000
- Cc: zsh-workers@xxxxxxx
- 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==
- In-reply-to: <92606-1558385755.382793@sll5.5oha.0as1>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAEpdsiaGRHHZMnV1Aq7+9wwZpE3qH9dV4c-jVfTxMRO810TyHg@mail.gmail.com> <92606-1558385755.382793@sll5.5oha.0as1>
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 only
> 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¹.
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()?
- 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.
- 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
¹ https://subversion.apache.org/docs/community-guide/conventions.html#apr-pools
pushheap() ≈ { p = apr_pool_create(p); }
popheap() ≈ { tmp = p->parent; apr_pool_destroy(p); p = tmp; }
Messages sorted by:
Reverse Date,
Date,
Thread,
Author