Zsh Mailing List Archive
Messages sorted by:
Re: zsh 5.2 build with --enable-stack-allocation crashes on large environments
- X-seq: zsh-workers 39680
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: zsh 5.2 build with --enable-stack-allocation crashes on large environments
- Date: Tue, 18 Oct 2016 16:46:07 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=SIg4tIZygEj2jmyTChL3WfTIiCn6jCtRFgx48xh7ODI=; b=r4hoHJoU6qD9w1LEhLwHUnS58Qox0U4wQl6BD0xJnFg+1uGXyOWHm/rRL1hIUR20t+ /SSJnj9Q5XHcID5q+7ZGwou1wST/Q1peBos+D51AytD5OES8nIwEyxbI59Fhn/ogjTaJ 534JirDGSdCLZlS0uKGVioY/nlD09y8K8qaKGEGIY1pfUaHXyXTCv2QpvQj1jDPfOIC6 M5TnytX55RhtJ0HqLuQLaF+Y4hzugBLdHjjTwouJ0H5t36AES0qIz8CDvODd4b8TNXXn HdZHkRxktTpcJujhheJGxss05/0lj9ORL1oKV66h+MCgoXkSLBAV2X5FNfuDzieYbCjf MQbw==
- In-reply-to: <email@example.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <firstname.lastname@example.org>
On Oct 18, 1:27pm, Charles Daffern wrote:
} The large environment variable causes zsh to crash on launch. Equally, a
} large number of environment variables has the same effect.
} The above breakpoint is on the munmap in popheap. The entire "heaps"
} variable is being freed at one point (because "h" is freed and they
} became equal for some reason). I'm not familiar enough with the code to
} figure out how this is happening though.
This would not be unusual in the event of a popheap() -- the whole point
is to be able to discard in one go at pop everything that was allocated
since the push.
With --enable-stack-allocation, the only uses of the heap up to the
point of your segfault are for the split_env_string() function, which
means that pushheap() in createparamtable() is a no-op because no heap
space has yet been allocated to need pushing.
This breaks an assumption in popheap() that there will always be at
least one ->next in the chain that points to memory belonging to a
pushheap() or zhalloc() from somewhere farther back in the call stack.
This is harmless if only a single "arena" has been used by the time
that popheap() is called, but with a large enough chunk needed by
split_env_string() there will be a second arena with no predecessor.
This is handled in freeheap() by leaving the munmap/free for popheap.
I'm not thrilled from the standpoint of all of our work to optimize
mem.c about having to special-case this in popheap() too, but the other
option is to special-case it in pushheap() which is worse, or to find
somewhere to allocate an unnecessary fragment of memory to be an arena
that's never released.
diff --git a/Src/mem.c b/Src/mem.c
index a1744c6..8c7eb80 100644
@@ -497,7 +497,8 @@ popheap(void)
h->next = NULL;
+ } else if (hl == h) /* This is the last arena of all */
+ hl = NULL;
munmap((void *) h, h->size);
Messages sorted by: