wx.PrintDialog segfaults if after "import gtk"

Hi everyone!

I'm building a wxPython application and I just came across a strange crash.. If I try to create a wx.PrintDialog after importing the gtk module, the program segfaults immediately.
Here's how to recreate the bug:

import wx
import gtk

app = wx.PySimpleApp()
wx.PrintDialog(None).ShowModal()
app.MainLoop()

If I run this testcase, I get the following:

GnomePrint-WARNING **: Could not create filter from description 'GnomePrintFilterSelect': filter 'GnomePrintFilterSelect' is unknown
Segmentation fault

If I leave out the "import gtk", the program shows the dialog (after throwing a bunch of warnings)

GnomePrint-WARNING **: Could not create filter from description 'GnomePrintFilterSelect': filter 'GnomePrintFilterSelect' is unknown

GLib-GObject-WARNING **: invalid (NULL) pointer instance

GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

GnomePrint-WARNING **: Could not create filter from description 'GnomePrintFilterClip [ GnomePrintFilterMultipage ]': filter 'GnomePrintFilterClip' is unknown

GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

libgnomeprintui-CRITICAL **: gnome_print_layout_selector_load_filter: assertion `GNOME_IS_PRINT_FILTER (f)' failed

GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

Please note that the problem emerges as soon as I instantiate the dialog, not by calling ShowModal()

I'm attaching a gdb backtrace.. Any hint on what I could try next? Should I open a bug report for wxPython?

I'm running Xubuntu 9.04 with wxPython 2.8.9.1, but I could reproduce the error on Ubuntu 10.04 too.

Thanks for your attention!

gdb.txt (5.59 KB)

I've just found a workaround, calling

gtk.remove_log_handlers()

avoids the segfault.

···

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Federico Fanton wrote:

I'm building a wxPython application and I just came across a strange crash.. If I try to create a wx.PrintDialog after importing the gtk module, the program segfaults immediately.

I wouldn't expect you to be able to use both the gtk and wxPython packages at one -- I imagine they'd stomp all over each other in all sorts of ways.

Why are you trying to do that?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Makes sense. The backtrace indicates that pygtk is trying to raise a Python warning in response to the GTK log message, but it looks like it is assuming that the current thread still has the GIL but it doesn't (or isn't able to get it for some reason.) My guess is that if the log message had happened while in a pygtk call then it would still have the GIL and all would be okay. Since wxPython releases the GIL whenever (mostly) it makes calls out to wx code then it won't have the GIL at the time that the log message happens.

···

On 5/7/10 7:00 AM, Joril wrote:

I've just found a workaround, calling

gtk.remove_log_handlers()

avoids the segfault.

--
Robin Dunn
Software Craftsman

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Well I need to be able to tell which workspace (virtual desktop) a
frame is in, and the only method I've found is by calling a little
tool called wmctrl and passing it the xid of the given window.. To
find out the xid I need to use pygtk, but if wxPython isn't supposed
to work along pygtk (I mean, by design/choice) I'll try to find
another way..
Thanks for your help!

···

On 7 Mag, 18:46, Chris Barker <Chris.Bar...@noaa.gov> wrote:

I wouldn't expect you to be able to use both the gtk and wxPython
packages at one -- I imagine they'd stomp all over each other in all
sorts of ways.

Why are you trying to do that?

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

I see.. So is it safe to say that a wxPython program isn't supposed to
make pygtk calls? And by this I mean "weird things could happen and it
would be too troublesome to fix it"? :slight_smile:

Thanks for your time!

···

On 7 Mag, 20:06, Robin Dunn <ro...@alldunn.com> wrote:

Since wxPython releases the GIL whenever
(mostly) it makes calls out to wx code then it won't have the GIL at the
time that the log message happens.

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

Joril wrote:

Well I need to be able to tell which workspace (virtual desktop) a
frame is in, and the only method I've found is by calling a little
tool called wmctrl and passing it the xid of the given window.. To
find out the xid I need to use pygtk,

You may be able to get the xid from wxPython -- Robin would know.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

It looks like as long as it is done in a way that won't confuse pygtk (such as causing pygtk to make callbacks to Python code while within a wx C++ call or idling in the main loop) then it will probably be okay.

···

On 5/10/10 12:42 AM, Joril wrote:

On 7 Mag, 20:06, Robin Dunn<ro...@alldunn.com> wrote:

Since wxPython releases the GIL whenever
(mostly) it makes calls out to wx code then it won't have the GIL at the
time that the log message happens.

I see.. So is it safe to say that a wxPython program isn't supposed to
make pygtk calls? And by this I mean "weird things could happen and it
would be too troublesome to fix it"? :slight_smile:

--
Robin Dunn
Software Craftsman

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

In the wxGTK port wx.Window.GetHandle returns the X-Window.

···

On 5/10/10 12:26 AM, Joril wrote:

On 7 Mag, 18:46, Chris Barker<Chris.Bar...@noaa.gov> wrote:

I wouldn't expect you to be able to use both the gtk and wxPython
packages at one -- I imagine they'd stomp all over each other in all
sorts of ways.

Why are you trying to do that?

Well I need to be able to tell which workspace (virtual desktop) a
frame is in, and the only method I've found is by calling a little
tool called wmctrl and passing it the xid of the given window.. To
find out the xid I need to use pygtk, but if wxPython isn't supposed
to work along pygtk (I mean, by design/choice) I'll try to find
another way..

--
Robin Dunn
Software Craftsman

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

I tried that, but it returned a handle that wasn't recognised by
wmctrl... To get to the "right" handle, I have to go up the widget
hierarchy:

gdkwin = gtk.gdk.window_lookup(frame.GetHandle())
win = gdkwin.get_user_data() #
http://library.gnome.org/devel/gdk/unstable/gdk-Windows.html#gdk-window-get-user-data
while not isinstance(win, gtk.Window): # Previous instances are
"gtk.Pizza"'s
    win = win.get_parent()
return win.window.xid

Don't know if there's a wx-only way..

···

On 10 Mag, 20:08, Robin Dunn <ro...@alldunn.com> wrote:

> Well I need to be able to tell which workspace (virtual desktop) a
> frame is in, and the only method I've found is by calling a little
> tool called wmctrl and passing it the xid of the given window.. To
> find out the xid I need to use pygtk, but if wxPython isn't supposed
> to work along pygtk (I mean, by design/choice) I'll try to find
> another way..

In the wxGTK port wx.Window.GetHandle returns the X-Window.

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

I managed to remove every occurrence of "import gtk" from my project,
and the PrintDialog works correctly..
There's a problem though: a new feature requires me to use pypoppler,
and it uses gtk internally, so I'm back to square one.. :frowning:
I was wondering: I noticed that with wx 2.9 the print framework
changed its Linux backend (gtkPrint instead of libgnomeprint), so
would this "incompatibility" with GTK go away? (I'm using 2.8.9.1 on
Xubuntu 9.04)

···

On 11 Mag, 09:03, Joril <jor...@gmail.com> wrote:

> > Well I need to be able to tell which workspace (virtual desktop) a
> > frame is in, and the only method I've found is by calling a little
> > tool called wmctrl and passing it the xid of the given window.. To
> > find out the xid I need to use pygtk, but if wxPython isn't supposed
> > to work along pygtk (I mean, by design/choice) I'll try to find
> > another way..

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

The problem is not specifically with printing, and also not directly related to mixing GTK and wxGTK either. The problem is that pygtk is intercepting any gtk error and warning log messages and trying to invoke Python code in response to them. The code doing that is assuming that the thread still has the GIL. If the error/warning message is coming in response to a pygtk call then it probably does still have the GIL and all is well. If the gtk error/warning message is in response to something that wxGTK does then it won't have the GIL (because wxPython releases it around C/C++ function calls) and the problem happens.

So, with using pypoppler it probably boils down to this: If pypoppler uses pygtk from Python code, and if you don't use the remove_log_handlers() workaround, then you'll likely have the same problem. If it just uses GTK from C code then you probably won't have any problems because there won't be any Python code called in response to log messages.

···

On 5/13/10 3:08 AM, Joril wrote:

On 11 Mag, 09:03, Joril<jor...@gmail.com> wrote:

Well I need to be able to tell which workspace (virtual desktop) a
frame is in, and the only method I've found is by calling a little
tool called wmctrl and passing it the xid of the given window.. To
find out the xid I need to use pygtk, but if wxPython isn't supposed
to work along pygtk (I mean, by design/choice) I'll try to find
another way..

I managed to remove every occurrence of "import gtk" from my project,
and the PrintDialog works correctly..
There's a problem though: a new feature requires me to use pypoppler,
and it uses gtk internally, so I'm back to square one.. :frowning:
I was wondering: I noticed that with wx 2.9 the print framework
changed its Linux backend (gtkPrint instead of libgnomeprint), so
would this "incompatibility" with GTK go away? (I'm using 2.8.9.1 on
Xubuntu 9.04)

--
Robin Dunn
Software Craftsman

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

I see, thanks for the detailed explanation :slight_smile:

···

On 13 Mag, 18:17, Robin Dunn <ro...@alldunn.com> wrote:

The problem is not specifically with printing, and also not directly
related to mixing GTK and wxGTK either. The problem is that pygtk is
intercepting any gtk error and warning log messages and trying to invoke
Python code in response to them.

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en