[pygtk] Problem with the GC starting in the middle of _wrap_gtk_window_list_toplevels

[Hrvoje Niksic]

Margarita Manterola wrote:
> The garbage collector is called while the code is in the for loop, it
> removes one of the toplevel windows which is not in use anywhere,
> except that it's already on the list, thus after the GC returns and
> the loop tries to access that removed window, it triggers a segfault.
> 
> I can think of one ugly solution, but no correct solution.  The ugly
> solution would be to add extra checks everywhere, so that if a window
> was destroyed in the middle of the function, everything would still
> work.  The correct solution would be to somehow prevent the GC from
> destroying the unused window which is still in the list, but I have no
> idea how.
> 
> Any ideas on how to fix it?

I'm not sure about a correct fix, but it's a bit worrying that the C 
backtrace is showing no signs of GC.  Why not add code that disables the 
GC and reenables it around the loop?  Something like:

// error checking elided for brevity
static PyObject *gc_module;
if (!gc_module)
   gc_module = PyImport_Import("gc");
PyObject *ret;
ret = PyObject_CallMethod(gc_module, "disable", "");
Py_DECREF(ret);

... loop goes here ...

ret = PyObject_CallMethod(gc_module, "enable", "");
Py_DECREF(ret);

If this removes the crash, then it's a good confirmation that it's 
gc-related.  A workaround could be to disable the GC as shown above.

A correct fix should consider how it's possible for the GC to get 
triggered for an object that it's already on the list?  The GC should 
only be invoked on objects that are only reachable by members of their 
cycle, whereas your object is clearly visible from the outside, because 
you're holding a reference to the list that leads to it.

Maybe you're seeing a weird corner case of 
http://bugzilla.gnome.org/show_bug.cgi?id=546802 which is known to cause 
GC to prematurely break cycles which it shouldn't.  I'd try applying the 
fix for that bug, maybe it helps.