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.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, 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 e1a1a55e for ; Tue, 21 May 2019 22:20:23 +0000 (UTC) Received: (qmail 24057 invoked by alias); 21 May 2019 22:20:12 -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: 44348 Received: (qmail 7867 invoked by uid 1010); 21 May 2019 22:20:12 -0000 X-Qmail-Scanner-Diagnostics: from mail-lj1-f173.google.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(209.85.208.173):SA:0(-1.9/5.0):. Processed in 1.678732 secs); 21 May 2019 22:20:12 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.208.173 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=obk8WPVxMH+EcwAsAy9lh8h3rnhtZq2IENxVacUKJO8=; b=jQwUrVik2RNE+tMXa+MjwZtL1z2AV2mcAl8v4ylNWj7j2hLzTE+q6AbIkNhjnQwpjk QPaxb4dRNjcvPixvzRAKHh+RoPXXmXJbi+c6R1nSLwgpcK7+DWp5zg9wmmGzEr8U1sbP kYeMZOepPKri0Ii+BThoFg6J0KfjD9Mg6icpS0cTllTBALunsVmteI08EOHUY+Rt+ZTu qNffmoAcBMDCCW9ZxHIgvQ5d+mkXBXXvZykeCRjtN/fFhNuc4ggLiPHoXPdOmZ17fEEw f14po6gqPwjZ51Bwo9r4iEyPdcmYLbWVTwRIVmFTfcLXht2Ty0nMBSor4b+tlCpIviHj dSCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=obk8WPVxMH+EcwAsAy9lh8h3rnhtZq2IENxVacUKJO8=; b=JgOAaBxCqQ2wChsNsJYgce7HNJp6QWmkda2obyIIvNfVcoiTAETBtKbJUQm7RQtTc3 tIk+c+rN4ZSIPMkLmlFjbkDCVg/g0F9gNzbDAKsu0P4/VkhCOyG2G1w5eU/V++VIN1nT UEopXoCrxnyNC7QOPvuqdOM5ZmEUaLkR37xy/Foj25c3PEzbjeiUeCKKGyAZQLnG76JK WnlGqz/szx/PFmahr64nEBINDnnxFUsIeK9RlD3Al+LYiDi5nK5gAyeG3aiLOhZJMyST eEhcf8CoKQQabXAaFfAujc3X/Rky+MSEwFUu9U0+u3CCVhT9KRRZfPJx/vzaUtwTdpSp NIpA== X-Gm-Message-State: APjAAAVpvlgNr24YlokiZDqdoJSCB+Ddna0HZMxQss5Gz93h3Q8LZYR9 FdeqBwixu0Q1WxXnlZoePfNr0LTGjs2hVyYb916dlQ== X-Google-Smtp-Source: APXvYqyNu5evoRCmUDhIwLSmrz6R9vlmI+wTRIwAGB4cxCb1Pblk4i5Oxqmf7x7rt3hi770rqeQhD+01BP0672gTDp4= X-Received: by 2002:a2e:a294:: with SMTP id k20mr6007086lja.118.1558477175653; Tue, 21 May 2019 15:19:35 -0700 (PDT) MIME-Version: 1.0 References: <92606-1558385755.382793@sll5.5oha.0as1> <90e15b90-14bb-4ef0-9aef-cc15c0fa0935@www.fastmail.com> In-Reply-To: <90e15b90-14bb-4ef0-9aef-cc15c0fa0935@www.fastmail.com> From: Bart Schaefer Date: Tue, 21 May 2019 15:19:23 -0700 Message-ID: Subject: Re: segfault via completion menu To: Daniel Shahaf Cc: Oliver Kiddle , Wesley Schwengle , "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" On Tue, May 21, 2019 at 2:59 PM Daniel Shahaf wrote: > > 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. Operationally, the difference between pushheap() and NEWHEAPS() is that pushing scans the entire list of existing heap blocks and moves them out of the way in favor of new empty blocks. This is time-consuming and eats a lot of memory if you're in a tightly recursive function (read back through the articles leading up to the change). In contrast, NEWHEAPS() just starts an entirely new chain of heap blocks without reference to the existing chain. If an error occurs as a result of NEWHEAPS()/OLDHEAPS() in the context of workers/36853, it ought to be traceable to something leaking heap-allocated storage across boundaries, and probably means there was a memory leak when interrupting a pattern match before, which this has turned into an error by freeing the previously leaked space.