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 a6b51319 for ; Wed, 18 Dec 2019 10:45:39 +0000 (UTC) Received: (qmail 5055 invoked by alias); 18 Dec 2019 10:45: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: List-Unsubscribe: X-Seq: 45083 Received: (qmail 9747 invoked by uid 1010); 18 Dec 2019 10:45:33 -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/25663. spamassassin: 3.4.2. Clear:RC:0(210.118.77.12):SA:0(-7.0/5.0):. Processed in 1.613781 secs); 18 Dec 2019 10:45:33 -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 20191218104459euoutp025e3abef9e08ddbc6afd7e747c0245bff~hcUgatuBO2463724637euoutp023 X-AuditID: cbfec7f4-0cbff7000001ed07-1a-5dfa032a284c Message-ID: <1576665897.4536.17.camel@samsung.com> Subject: Re: =?ISO-8859-1?Q?Re=A0=3A?= Re: =?ISO-8859-1?Q?Re=A0=3A?= [BUG] Crash due to malloc call in signal handler From: Peter Stephenson To: , Antoine C. Date: Wed, 18 Dec 2019 10:44:57 +0000 In-Reply-To: <1576663298.4536.12.camel@samsung.com> X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsWy7djP87pazL9iDaY+NLPYdMHe4mDzQyYH Jo/+dZ9ZPVYd/MAUwBTFZZOSmpNZllqkb5fAlXH1y1/Ggrm8FfcurGJuYHzL1cXIySEhYCJx au1N5i5GLg4hgRWMEs/2HmaHcL4wSvQ+W8MEUiUk8JlR4tAZMZiOL1MPs0IULWeU+NbUzwjh ABV1X/7NBuGcYZRYdPI+E4RzgVHiQNM3FpB+XgEjiem3vjGC2MIC5RL7D/9gBrHZBAwlpm6a DRYXEbCQ6Jp+DWgHBweLgKrE9Q4vkDCngLHEvys32SDO0JDYcPMYE8RIQYmTM5+AjWcWkJdo 3job7CEJgc9sEk1zjoHNkRBwkTj9IQeiV1ji1fEt7BC2jMT/nfOZIOrbGSXWTHrNDuH0MEps OnqHEaLKWqLv9kVGkEHMApoS63fpQ4QdJda8b2KGmM8nceOtIMQNfBKTtk2HCvNKdLQJQVSr Sexo2soIEZaReLpGYQKj0iwkD8xC8sAshFULGJlXMYqnlhbnpqcWG+WllusVJ+YWl+al6yXn 525iBKaG0/+Of9nBuOtP0iFGAQ5GJR5eA4afsUKsiWXFlbmHGCU4mJVEeG93AIV4UxIrq1KL 8uOLSnNSiw8xSnOwKInzGi96GSskkJ5YkpqdmlqQWgSTZeLglGpg7NPwsn6z9bX5QgcFljks T/l/Hf/Rvvltd+feg7Nu7d3/w/Po76rMmI50nuveu1SLA3e/vrNUkX3hpA2r+FoL579e68op JMfomPrS8fhxXb0F1hzaa9XPrWPW5ir+8C7IJuPL/13X6iY7LjHO+Kx7ooYrTs+hcWX/nqqX Z+7xRqsFVKqvy598T4mlOCPRUIu5qDgRAKVjg/EJAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42I5/e/4PV0t5l+xBt+PyFhsumBvcbD5IZMD k0f/us+sHqsOfmAKYIrSsynKLy1JVcjILy6xVYo2tDDSM7S00DMysdQzNDaPtTIyVdK3s0lJ zcksSy3St0vQy7j65S9jwVzeinsXVjE3ML7l6mLk5JAQMJH4MvUwaxcjF4eQwFJGiXMfrjJC JGQkPl35yA5hC0v8udbFBlH0kVHiyLIjLBDOGUaJh69XQrVfYJSYdfU7E0gLr4CRxPRb38BG CQuUS+w//IMZxGYTMJSYumk2WFxEwEKia/o1oGYODhYBVYnrHV4gYU4BY4l/V26ygdhCArcZ Jda8LwCxmQU0JVq3/4a6SENiw81jUKsEJU7OfMICUSMv0bx1NvMERqFZSFpmISmbhaRsASPz KkaR1NLi3PTcYiO94sTc4tK8dL3k/NxNjMB42Hbs55YdjF3vgg8xCnAwKvHw3vj7I1aINbGs uDL3EKMEB7OSCO/tjp+xQrwpiZVVqUX58UWlOanFhxhNgf6ZyCwlmpwPjNW8knhDU0NzC0tD c2NzYzMLJXHeDoGDMUIC6YklqdmpqQWpRTB9TBycUg2Mva+XyD5avre9abrtwYtqVv6nqp0O X/G2itwWm5cy/fLvV1/W1qso57+QdKqZk7Dm/7+PU9+9LGZc9OephTqXjv7mWM83It67GTZP nNPHFOO7zbm5nlU6/rrNXn9v/QyLmX5MH8SMs0LfL+GNKDk6r0Qo9mbzqy3+13d+C4x7XvP3 Q5ZCxyMTJZbijERDLeai4kQAZQLFCZ0CAAA= X-CMS-MailID: 20191218104458eucas1p1c73ef257ebe6f3f32407d0050fa91016 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20191217183216epcas1p1e81fb3dc675bab810e8d29ac0f53242c X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20191217183216epcas1p1e81fb3dc675bab810e8d29ac0f53242c References: <1548982683.1013827769.1576607530234.JavaMail.root@zimbra62-e11.priv.proxad.net> <1576663298.4536.12.camel@samsung.com> On Wed, 2019-12-18 at 10:01 +0000, Peter Stephenson wrote: > OK, the suspect here is the arithmetic code --- it looks like it's > running unprotected against signals, despite the fact it can set > variables.  Arithmetic is a quick operation, so hopefully we can block > fairly high up the stack.  I should get a chance to look later > (but I don't think this is rocket science from this point on so maybe > someone will beat me to it). >  > pws >  > >  > > #9  0x000055e115ce40f4 in zhandler (sig=17) at signals.c:648 > ... > >  > > #23 0x000055e115c7cddf in execarith (state=0x7ffea5b39110, do_exec=0) at exec.c:5111 Yes, it really does look this simple.  All top-level "exec" functions should be able to queue and unqueue signals without side effects, any issues being handled lower down, and execarith() is a good deal simpler than most of the others (which is probably why it never acquired the protection in the first place). I'll commit this fairly quickly --- it's obviously needed and in the event of side effects I'd rather find out sooner than later. pws diff --git a/Src/exec.c b/Src/exec.c index 50027654a..fac095d64 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -5101,6 +5101,7 @@ execarith(Estate state, UNUSED(int do_exec))      mnumber val = zero_mnumber;      int htok = 0;   +    queue_signals();      if (isset(XTRACE)) {   printprompt4();   fprintf(xtrerr, "(("); @@ -5120,6 +5121,8 @@ execarith(Estate state, UNUSED(int do_exec))   fprintf(xtrerr, " ))\n");   fflush(xtrerr);      } +    unqueue_signals(); +      if (errflag) {   errflag &= ~ERRFLAG_ERROR;   return 2;