After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 668563 - Raise exception instead of segv when trying to access already destroyed gobjects
Raise exception instead of segv when trying to access already destroyed gobjects
Status: RESOLVED DUPLICATE of bug 674050
Product: pygobject
Classification: Bindings
Component: gobject
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-01-24 10:35 UTC by Michael Vogt
Modified: 2012-04-20 13:01 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
test case (216 bytes, text/x-python)
2012-01-24 10:43 UTC, Michael Vogt 		Details

Description Michael Vogt 2012-01-24 10:35:54 UTC 
I had a bug in one of my pygi apps that was caused by a signal emited after the main window was already destroyed. This lead to a segfault in the app.

Attached is a small example that triggers the segfault. Now obviously the
code there is wrong and buggy. And yet it would be nice if pygobject would
have a way of raising a exception if python code tries to access a already
destroyed gobject instead of segfaulting.

Thanks!
 Michael
Comment 1 Michael Vogt 2012-01-24 10:43:45 UTC 
Created attachment 205958 [details]
test case

The attachment creation failed for some reason when I submitted it, here is the attachment again.
Comment 2 Tomeu Vizoso 2012-01-24 15:15:43 UTC 
Well, I don't think that code is wrong, as long as you have a reference to its Python wrapper, the GObject should be kept alive.

What we are seeing here is a missing incref, maybe a wrong annotation?
Comment 3 Martin Pitt 2012-04-20 13:01:43 UTC 
This looks like bug 674050.

As the crash is in GTK, not in pygobject, there is not much we can do here anyway.

The proper fix would be to disconnect all signal handlers before destroying objects, I think.

*** This bug has been marked as a duplicate of bug 674050 ***