[gtk+/gtk-2-24] (Backport acf1345) Fix refresh of static autorelease_pool so that it doesn't happen in gtk-nested lo

[John Ralls <jralls src gnome org>]

commit 224a7e798a4d7981f4ec1583f592bbde8573946b
Author: John Ralls <jralls ceridwen us>
Date:   Mon Jan 3 11:56:20 2011 -0800

    (Backport acf1345) Fix refresh of static autorelease_pool so that it doesn't happen in gtk-nested loops.

 gdk/quartz/gdkeventloop-quartz.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)
---
diff --git a/gdk/quartz/gdkeventloop-quartz.c b/gdk/quartz/gdkeventloop-quartz.c
index f11d4d8..6254203 100644
--- a/gdk/quartz/gdkeventloop-quartz.c
+++ b/gdk/quartz/gdkeventloop-quartz.c
@@ -632,15 +632,14 @@ gdk_event_check (GSource *source)
 
   GDK_THREADS_ENTER ();
 
-  /* XXX: This check isn't right it won't handle a recursive GLib main
-   * loop run within an outer CFRunLoop run. Such loops will pile up
-   * memory. Fixing this requires setting a flag *only* when we call
-   * g_main_context_check() from within the run loop iteraton code,
-   * and also maintaining our own stack of run loops... allocating and
-   * releasing NSAutoReleasePools not properly nested with CFRunLoop
-   * runs seems to cause problems.
-   */
-  if (current_loop_level == 0)
+`/* Refresh the autorelease pool if we're at the base CFRunLoop level
+  * (indicated by current_loop_level) and the base g_main_loop level
+  * (indicated by g_main_depth()). Messing with the autorelease pool at
+  * any level of nesting can cause access to deallocated memory because
+  * autorelease_pool is static and releasing a pool will cause all pools
+  * allocated inside of it to be released as well.
+  */
+    if (current_loop_level == 0 && g_main_depth() == 0)
     {
       if (autorelease_pool)
 	[autorelease_pool release];