From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8485 invoked by alias); 25 Jan 2016 15:31: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: 37776 Received: (qmail 29625 invoked from network); 25 Jan 2016 15:31:32 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f4-f79026d00000418a-19-56a63fcf2fc7 Date: Mon, 25 Jan 2016 15:31:25 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: infinite recursion when handling the "out of memory" state Message-id: <20160125153125.519298a7@pwslap01u.europe.root.pri> In-reply-to: <4775934.DA9sGOASTP@kdudka.brq.redhat.com> References: <4775934.DA9sGOASTP@kdudka.brq.redhat.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsVy+t/xy7rn7ZeFGZzs0bA42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGfeWeRR08lZsfd3A1MD4i7OLkYNDQsBE4kYnfxcjJ5ApJnHh 3nq2LkYuDiGBpYwS3xpOMUI4M5gklvy6xgThnGOUuDv5FjtIi5DAWUaJ+buNQWwWAVWJTb93 M4PYbAKGElM3zWYEsUUExCXOrj3PAmILC7hLLG2fAWbzCthLvLl4hRXE5hQwl+jaPJERYqaZ RO/WJUwgNr+AvsTVv5+YIM6zl5h55QwjRK+gxI/J98DmMAtoSWze1sQKYctLbF7zlhlijrrE jbu72ScwCs9C0jILScssJC0LGJlXMYqmliYXFCel5xrqFSfmFpfmpesl5+duYoSE8pcdjIuP WR1iFOBgVOLhtVBbGibEmlhWXJl7iFGCg1lJhPc/37IwId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rxzd70PERJITyxJzU5NLUgtgskycXBKNTA6n52oZTnVasUL2Zu3TzdaqSlyz/2gd8Uko6N7 2w/VvSt+9S68dPT3p2utF2XzxaMPdBh57dfmvJD9lfXBpR3LbwT5Kp/7cFVJyePPvaSUmtPx Upo9kjWyLyZWnbtyYDP32UMLpDftmnXA/dnUN+fEs+r+frhYWDmreJ6+3KTI/+YXwi2eii9r U2Ipzkg01GIuKk4EADAUPUJhAgAA On Mon, 25 Jan 2016 16:02:50 +0100 Kamil Dudka wrote: > If zsh is compiled with multibyte support, handling of the "out of memory" > state does not work well in certain cases -- instead of printing the error > message and exiting, zsh ends up in an infinite recursion and crashes due to > stack overflow. > > The memory allocation functions in mem.c use zerr() to print the fatal error > messages. However, zerr() calls zwarning() and transitively mb_niceformat(), > which allocates heap memory (and may call zerr() on failure). > > 3. introduce a flag that would prevent zerr() from recurring into itself I think this is easy --- we already do this except that the flag is set after the warning is printed rather than before. The zwarning() function that is called in the middle isn't directly sensitive to the flag, so moving the code up should have the desired effect and is the sane thing to do with error messages anyway. diff --git a/Src/utils.c b/Src/utils.c index fd0bab3..17ebfeb 100644 --- a/Src/utils.c +++ b/Src/utils.c @@ -169,12 +169,12 @@ VA_DCL errflag |= ERRFLAG_ERROR; return; } + errflag |= ERRFLAG_ERROR; VA_START(ap, fmt); VA_GET_ARG(ap, fmt, const char *); zwarning(NULL, fmt, ap); va_end(ap); - errflag |= ERRFLAG_ERROR; } /**/ @@ -188,13 +188,13 @@ VA_DCL if (errflag || noerrs) return; + errflag |= ERRFLAG_ERROR; VA_START(ap, fmt); VA_GET_ARG(ap, cmd, const char *); VA_GET_ARG(ap, fmt, const char *); zwarning(cmd, fmt, ap); va_end(ap); - errflag |= ERRFLAG_ERROR; } /**/