nanogui: [patch] GsError / GsAllocEvent and out of memory


Previous by date: 14 Feb 2003 21:02:26 -0000 How the server start to draw a window?, wangxq
Next by date: 14 Feb 2003 21:02:26 -0000 Correct value for SCREEN_PIXTYPE when building mwin for framebuffer, Patrick Kelly
Previous in thread:
Next in thread:

Subject: [patch] GsError / GsAllocEvent and out of memory
From: "Aaron J. Grier" ####@####.####
Date: 14 Feb 2003 21:02:26 -0000
Message-Id: <20030213192531.GK20557@aaron.unix.fryenet>

GsError and GsAllocEvent can get into a recursive loop if the system
runs out of memory.

if GsAllocEvent runs out of memory, it calls GsError, which calls
GsAllocEvent again, etc, and eventually the stack blows.

I've attached my simple-minded patch against 0.89.  any suggestions on
how to better handle this are of course welcome.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  ####@####.####

Index: 0-89.2/src/nanox/srvevent.c
--- 0-89.2/src/nanox/srvevent.c Wed, 12 Feb 2003 11:42:54 -0800 aaron (microwin/c/17_srvevent.c 1.5 644)
+++ 0-89pre8.3(w)/src/nanox/srvevent.c Thu, 13 Feb 2003 09:52:46 -0800 aaron (microwin/c/17_srvevent.c 1.5 644)
@@ -78,6 +78,11 @@
 	if (!curclient)
 		return;
 
+	/* if we ran out of memory, another call to GsAllocEvent will
+	 * simply get us back here, so don't bother trying to report the
+	 * event.  */
+	if (code == GR_ERROR_MALLOC_FAILED) return;
+
 	/* queue the error event regardless of GrSelectEvents*/
 	ep = (GR_EVENT_ERROR *)GsAllocEvent(curclient);
 	ep->type = GR_EVENT_TYPE_ERROR;

Previous by date: 14 Feb 2003 21:02:26 -0000 How the server start to draw a window?, wangxq
Next by date: 14 Feb 2003 21:02:26 -0000 Correct value for SCREEN_PIXTYPE when building mwin for framebuffer, Patrick Kelly
Previous in thread:
Next in thread:


Powered by ezmlm-browse 0.20.