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=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 afff35f1 for ; Fri, 13 Dec 2019 17:31:11 +0000 (UTC) Received: (qmail 29274 invoked by alias); 13 Dec 2019 17:31:06 -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: 45020 Received: (qmail 23175 invoked by uid 1010); 13 Dec 2019 17:31:06 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25656. spamassassin: 3.4.2. Clear:RC:0(210.118.77.12):SA:0(-7.0/5.0):. Processed in 2.997558 secs); 13 Dec 2019 17:31:06 -0000 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.samsung.com designates 210.118.77.12 as permitted sender) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20191213173025euoutp029a9b0d44c12095b6646f6be9150da9fe~f-oE-7Usg0162201622euoutp02c X-AuditID: cbfec7f5-a0fff7000001ed1a-5d-5df3cab12558 Message-ID: <1576258224.5214.31.camel@samsung.com> Subject: Re: =?ISO-8859-1?Q?TR=A0=3A?= =?ISO-8859-1?Q?_Re=A0=3A?= [BUG] Crash due to malloc call in signal handler From: Peter Stephenson To: Date: Fri, 13 Dec 2019 17:30:24 +0000 In-Reply-To: <569822988.994307929.1576256973462.JavaMail.root@zimbra62-e11.priv.proxad.net> X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsWy7djPc7obT32ONWj+KmVxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4MvYuamcsWCNSsexME0sD43+BLkZODgkBE4m9f/4xgthCAisY Jd635nYxcgHZfUwSPe/nMEE4vUwSuz4vY4fpmPlgEjNEYjmjxL/lz5nhqn7eOs0KMesMo8Su cxEQiQuMEu++rmMGSfAKGEls7fkKNJeDQ1igROLLvRKQMJuAocTUTbPB7hARkJS41nwazGYR UJXobrkLZnMKREvsX7GZFeIKDYkNN48xQYwUlDg58wkLiM0sIC/RvHU22EESAs/ZJG79XM8C 0eAicfzYFagXhCVeHd8CZctI/N85nwmioZ1RYs2k1+wQTg+jxKajdxghqqwl+m5fZAS5mllA U2L9Ln2IsKNE45kdzCBhCQE+iRtvBSGO4JOYtG06VJhXoqNNCKJaTWJH01ZGiLCMxNM1ChMY lWYh+WAWkg9mIaxawMi8ilE8tbQ4Nz212DgvtVyvODG3uDQvXS85P3cTIzARnP53/OsOxn1/ kg4xCnAwKvHwamz+HCvEmlhWXJl7iFGCg1lJhDdVGyjEm5JYWZValB9fVJqTWnyIUZqDRUmc 13jRy1ghgfTEktTs1NSC1CKYLBMHp1QDo3b+n7KwYmZxCaZi+cjVD/LVk1Y1zU3a9DBvnoPV ek2WQymfn14qevjMhdGufbeZa1hk+/ldawo3ramNMGeKvVN74GHXFRf+xtez1xkLJNlPXmM5 XfKp6pS6RpHP1aZ7Rdtu3EvLy2ZVOlttX6JebNq6P/95t7h/14FLf99eexG6laUncPd9JZbi jERDLeai4kQAmK9kPAADAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42I5/e/4Xd2Npz7HGjz5wm5xsPkhkwOjx6qD H5gCGKP0bIryS0tSFTLyi0tslaINLYz0DC0t9IxMLPUMjc1jrYxMlfTtbFJSczLLUov07RL0 MvYuamcsWCNSsexME0sD43+BLkZODgkBE4mZDyYxdzFycQgJLGWUWNTxkAkiISPx6cpHdghb WOLPtS42iKJuJomdj1pZIJwzjBLdzX+gMhcYJaZ9/MYM0sIrYCSxtecr0CgODmGBEokv90pA wmwChhJTN81mBLFFBCQlrjWfBrNZBFQlulvugtmcAtES+1dsZgWxhQTWM0p8XiMHYjMLaEq0 bv8NdZGGxIabx5ggVglKnJz5hAWiRl6ieets5gmMQrOQtMxCUjYLSdkCRuZVjCKppcW56bnF hnrFibnFpXnpesn5uZsYgcG/7djPzTsYL20MPsQowMGoxMOrsflzrBBrYllxZe4hRgkOZiUR 3lRtoBBvSmJlVWpRfnxRaU5q8SFGU6CHJjJLiSbnAyMzryTe0NTQ3MLS0NzY3NjMQkmct0Pg YIyQQHpiSWp2ampBahFMHxMHp1QDo0Ui74LXqavtd5+K+Cv7St/hxNx5nf/Ovgzctv5W7bmZ k16eumX+Ub238el1cfZvW4JP/Wbx8snSalrAd/qa9W3h5zPd9sc7/NDRzZ09zfyEyK9Uyztx Pit2VrR7fTnEO+GNL5vlszfH5k11WcvCeXxZztP6LyqzLhsU9l/Ku6T/k1lf79DPhAwlluKM REMt5qLiRAA1kkQwlAIAAA== X-CMS-MailID: 20191213173025eucas1p2a43c4a4e2136dc24432cebf52f1f1a0c X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20191213171028eucas1p2e7820377701008b2d05c898192b7c17e X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20191213171028eucas1p2e7820377701008b2d05c898192b7c17e References: <569822988.994307929.1576256973462.JavaMail.root@zimbra62-e11.priv.proxad.net> On Fri, 2019-12-13 at 18:09 +0100, Antoine C. wrote: > (and now zsh mail server is returning back all my mails  > to the list (????), so I am replying directly to you...) Looks like it got there, if I'm interpreting my email correctly, so I'll abbreviate for the response. > So Peter what I understand from your mails is that malloc > functions are called from signal handler on purpose, but  > only at the time you think is right, so even if it is  > forbidden, it should work... Well, it does not. There is > a backtrace at the end of the mail showing it clearly, but > we can dive into the details to understand what is happening. This trace is much more useful than the previous one, which I think was too late.... The readoutput function is indeed unqueueing signals, and also has some memory managament.  It's clear from the code there's an attempt to fix the issues, but there's obviously something left. If you're using the current git source, exec.c line 4673 has a call to fgetc(), which is indeed outside where signals are queued.  Are you able to confirm this is correct? I think the intention here is to make sure we're not blocking for a long time in this function, but if fgetc() is doing memory allocation we're going to have to put that in the signal blocking.  However, if the input itself blocks in fgetc() that's going to be a problem.  The fix might be not to fdopen() the input file, but just read into a buffer with read(). Here's the relevant chunk, though on the last line, and the fact there's a memory allocation with a signal handle on top of it, are really important. #7  0x00005555556008d5 in zhandler (sig=17) at signals.c:648 #8   #9  0x00007ffff7314a55 in _int_malloc (av=av@entry=0x7ffff7643bc0 , bytes=bytes@entry=4145) at malloc.c:4149 #10 0x00007ffff7315be6 in __GI___libc_malloc (bytes=4145) at malloc.c:3088 #11 0x00007ffff7318335 in mallochook (size=4096, caller=0x7ffff72ff459 <__GI__IO_file_doallocate+121>) at mcheck.c:311 #12 0x00007ffff7315d4a in __GI___libc_malloc (bytes=bytes@entry=4096) at malloc.c:3057 #13 0x00007ffff72ff459 in __GI__IO_file_doallocate (fp=0x55555589aba0) at filedoalloc.c:101 #14 0x00007ffff730e379 in __GI__IO_doallocbuf (fp=fp@entry=0x55555589aba0) at genops.c:347 #15 0x00007ffff730d26c in _IO_new_file_underflow (fp=0x55555589aba0) at fileops.c:490 #16 0x00007ffff730e3f2 in __GI__IO_default_uflow (fp=0x55555589aba0) at genops.c:362 #17 0x00005555555980bc in readoutput (in=12, qt=1, readerror=0x0) at exec.c:4673 pws