Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
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 <p.stephenson@samsung.com>
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
X-Seq: zsh-workers 37776

On Mon, 25 Jan 2016 16:02:50 +0100
Kamil Dudka <kdudka@redhat.com> 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;
 }
 
 /**/