From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15657 invoked by alias); 25 Feb 2018 00:13:43 -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: 42400 Received: (qmail 12896 invoked by uid 1010); 25 Feb 2018 00:13:43 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f195.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.192.195):SA:0(1.2/5.0):. Processed in 2.465047 secs); 25 Feb 2018 00:13:43 -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=1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, FSL_HELO_FAKE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: joeypabalinas@gmail.com X-Qmail-Scanner-Mime-Attachments: |signature.asc| X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4+U0inzWJYKrePFT3S55WYjQuxOmLmEZmSkdvqhMHy0=; b=a/9+XOHZcOwt2RsKleojteZ3B2rUmmDAW/xFToTdGoh1QtVaxijearnkDVusm3JF7X nkqD9g1KqrqKTPZNVQXZeVbWu4etdWBXOnRDiQC+0U7wpC3Y0jPDH9F5KrG9JLfe9h4c UxaO4T3zWd9NMDWq0xUd3ngZi2Ysrts9TfgIsmn8kiTxPMQTJWPKhwAHY8YBkOOubUe0 x9avfQ7wgGWE/rTbMM7zDvMhbK3P4PuAe2J3tpJx7UeyKsQmmJFUIl0lHN0T1LV0L1Sg IcCtHmBSGHCaEBacbmyCbPHhdIzVW5gH++/ME0WgwwGqlPknG5Mb/vOPAKauWAHY/smQ DUXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=4+U0inzWJYKrePFT3S55WYjQuxOmLmEZmSkdvqhMHy0=; b=SOVOYgFSe8jIYACvoSwx/zeV8v9bQRS5CCfgPD4yro7nAEIDMpNbwwIElJscGCDp3w ZLE6OQ7S5NsFv5gzxxJMNKhTEkpsZEel/CNKWo95Gh5wacJc0tOYDNntOY2A9vopwnej 92ZUSlG7YyUPlWttN7Pvb2/o4R+blL8bDyhBdMVou8D0/nHKn9mQMoGh+i9Mr25COcn9 befMWSoIV930hiDeM5Nt18LkW+Q5xw8oyAHjEOmzb5t6OxbDW+J49XvoW68E/IV/j4L2 SJJqhhoXYBDWajfhcmHPjrnZzHWOeYEi1t3Znp1VsrwdpWJj0HkajjOPUPwntRDsK7b/ SfEg== X-Gm-Message-State: APf1xPA2DMAKWSFsRn8UTQfLv5LxNcLS27drebA4qio36MwNBqD7H5SS S2qV/dthY72YOyvtPYW0AvFi+Q== X-Google-Smtp-Source: AH8x227wisJf71bG6vidGewCvF6AY4JPfnZxzyJnjhlW+lsaL9FIUJNBcOogXxRSH9AqToV0gRk3DQ== X-Received: by 10.99.184.1 with SMTP id p1mr4893594pge.96.1519517618129; Sat, 24 Feb 2018 16:13:38 -0800 (PST) Date: Sat, 24 Feb 2018 14:13:34 -1000 From: Joey Pabalinas To: Mikael Magnusson Cc: zsh workers , Joey Pabalinas Subject: Re: crash/hang with gcc 5+ -O2 and --enable-zsh-mem Message-ID: <20180225001334.fzsdcy67cnosvj5z@gmail.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="236ggd6kvp622ltp" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 --236ggd6kvp622ltp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 24, 2018 at 08:01:28PM +0100, Mikael Magnusson wrote: > I figured out this was because of -foptimize-strlen which somehow > causes calloc() to recurse infinitely and crash (with -O2 which also > enables -foptimize-sibling-calls it just hangs with no crash because > it doesn't consume extra stack, i presume). What I don't know is how > to fix it, or the causal relationship between strlen optimization and > calloc recursing infinitely. I've tried gcc 5.4, 6.2 and 6.4 with the > same result. Compiling only Src/mem.c with the problematic flag is > enough so it's something in there, but removing the one strlen() call > in the file has no effect. I am also seeing the same behavior, and to be completely honest I have no idea how strlen() is related either. Some testing in gdb did show that you were right; the problem is a loop caused by a repeated jump back to line 1719, which definitely lines up with the `-foptimize-sibling-calls` part. The only fix I could find which didn't requiring substantial reimplementation of the memory management functions was to replace the malloc() call in calloc() with realloc() instead. With a NULL `p` argument realloc() behaves exactly the same as malloc() does, and (at least on my system) gcc doesn't seem to consider realloc() a candidate for sibling call optimizations; give this patch a try and _hopefully_ this is a viable solution. Signed-off-by: Joey Pabalinas 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Src/mem.c b/Src/mem.c index 840bbb6e4a4eb6fd73..8b0dafed6fdae35a61 100644 --- a/Src/mem.c +++ b/Src/mem.c @@ -1714,12 +1714,18 @@ MALLOC_RET_T calloc(MALLOC_ARG_T n, MALLOC_ARG_T size) { long l; - char *r; + char *r =3D NULL; =20 if (!(l =3D n * size)) return (MALLOC_RET_T) m_high; =20 - r =3D malloc(l); + /* + * use realloc() (with a NULL `p` argument it behaves exactly the same + * as malloc() does) to prevent an infinite loop caused by sibling-call + * optimizations (the malloc() call would otherwise be replaced by an + * unconditional branch back to line 1719 ad infinitum). + */ + r =3D realloc(r, l); =20 memset(r, 0, l); =20 --=20 2.16.2 --236ggd6kvp622ltp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKlZXrihdNOcUPZTNruvLfWhyVBkFAlqR/64ACgkQruvLfWhy VBkSJQ//e7otJp/sjIuM9eGiNBl6/k6SwHD3JPNzmoYQBZKnrisK1eRsnqttEtWi mKSQ6OvmGREojedBIh2h00AsdTDh/6o/4/mF579QYvLjmdEkYkm81mmibDziR5HE 9YdP4X61EePBbEXIJAA+os8LxFtaNJurHas5+9skiJKPEnt8F39TN8HT3dxq03DF ZzA4ac6gtEShm5xSujZNTGzdhYRplfpG9WUWvwZVPFRqj54zaHFIy2HZatZwobRv MfP6xXwmmHoTEjOD6lxwY39224ShtLNIPgRtUI2zIIlYPNbi88/jcFIatG2xgKWy i0OutomKMeADXqwRhYrMvP17KYBUN56GpVdcQps5iMDzCepsr/MSxCd8/RsAIKdX iRo++xDgdiimlhZ2snx92nZ4YRaam8edmbGBC2sQACVxJSVO+2Hhp2kiPLY47nL2 JeKOOV8L400nD5LM7vT7wIY2NVsAT8DLG6/+1xGwf+U2Q1bopp7FC5OFK2KLOVCz uR6Ez19kFsLl/JHaSjK+hMwZVZT4F/ITBtv+Mn/9hlazs9MRf5pDPmS1JSRf4nbO pzbLKGMwZPakzMs5RaN9igrfdeFHjf7vY30SRD4uVAEam3iwDkM8kbprtbjJA1P2 ds2FT4139s6RYI07U75+VwK2ctwN8BGGF/nLdLMgvwGmrM3uI7I= =Dz/N -----END PGP SIGNATURE----- --236ggd6kvp622ltp--