From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5275 invoked by alias); 19 Oct 2016 13:40:34 -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: 39680 Received: (qmail 7836 invoked from network); 19 Oct 2016 13:40:34 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f54.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.54):SA:0(0.0/5.0):. Processed in 0.772934 secs); 19 Oct 2016 13:40:34 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) 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== 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; bh=SIg4tIZygEj2jmyTChL3WfTIiCn6jCtRFgx48xh7ODI=; b=eH0zA3CaYYvuJKXkyc+LZToD1PSMHW76CiyevJwx+Lm9d5EpjzRe98vqFfcH4ktD3j WLXFHp1bW8JxA7dh17Txt4IIibu4Yok/xQTZTJD5/8WOGAeJuBdQCV6B+N51C3qusnq0 D/hsaia9S/MPVGoaB427I18Sy0XaEu2BQw2muozHHtIOHUJhnKp+MHHyqclMBDVppXUI q0X8NGN4v9kuFGsZXynB0B/MrR7PN727oIqPtt8/BtsAw5abRl437cirlZNTq3giR/rn Fm8LMd/fLzzmZcyg0Ddbw5i6aXpXGlbjIYuv5RSmL0+/n6oMNUd27kokH0cDK4ciES11 6Mlw== X-Gm-Message-State: AA6/9Rn9p0kVFO3bnRbWkfF6nU9rZ4TCawD6lfM5MF93K3ML0GmSFhmhb20+MswBR36Uig== X-Received: by 10.31.3.25 with SMTP id 25mr2875616vkd.116.1476834369387; Tue, 18 Oct 2016 16:46:09 -0700 (PDT) From: Bart Schaefer Message-Id: <161018164607.ZM26901@torch.brasslantern.com> Date: Tue, 18 Oct 2016 16:46:07 -0700 In-Reply-To: <5aa037f1-d019-8186-89f6-16a5a48d550a@gmail.com> Comments: In reply to Charles Daffern "zsh 5.2 build with --enable-stack-allocation crashes on large environments" (Oct 18, 1:27pm) References: <5aa037f1-d019-8186-89f6-16a5a48d550a@gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: zsh 5.2 build with --enable-stack-allocation crashes on large environments MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 --- a/Src/mem.c +++ b/Src/mem.c @@ -497,7 +497,8 @@ popheap(void) continue; } h->next = NULL; - } + } else if (hl == h) /* This is the last arena of all */ + hl = NULL; #ifdef USE_MMAP munmap((void *) h, h->size); #else