325884 - race? crash in EmbedPrivate::Realize with gtkmozembed

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: GTK Widget, defect)

Description

[Ian Jackson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060204 Ubuntu/1.5.dfsg-4ubuntu6 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060204 Ubuntu/1.5.dfsg-4ubuntu6 Firefox/1.5

https://launchpad.net/distros/ubuntu/+source/firefox/+bug/26436 reports that the python gtkmozembed support crashes on startup.  This crash is not 100% reproduceable and not solely linked with the python plugin.  You'll see simple Python and C test programs, both of which have been made to crash at least some of the time, so the problem is not strictly related to Python.  Compiling without -O2 makes the crash much less likely.

Investigating with a debugger shows that
 mWindow->mBaseWindow->GetMainWidget(getter_AddRefs(mozWidget));
(EmbedPrivate.cpp line 277) leaves mozWidget==0.  The GetMainWidget being used is in nsWebBrowser.cpp l1452- and both mInternalWidget and mParentWidget are 0.

Looking at the code (which I don't really understand properly) it would seem that these are supposed to be set by nsWebBrowser::Create but setting a breakpoint there didn't trigger so I think it's not being called.  I don't know where (or indeed whether) it should be called.

Reproducible: Sometimes

Steps to Reproduce:




Program received signal SIGSEGV, Segmentation fault.
0xb72a0fe1 in EmbedPrivate::Realize (this=0x82412e8, aAlreadyRealized=0xbfffe718) at EmbedPrivate.cpp:280
280         NS_STATIC_CAST(GdkWindow *,
(gdb) bt
#0  0xb72a0fe1 in EmbedPrivate::Realize (this=0x82412e8, aAlreadyRealized=0xbfffe718) at EmbedPrivate.cpp:280
#1  0xb729e9e9 in gtk_moz_embed_realize (widget=0x81ada88) at gtkmozembed2.cpp:606
#2  0xb7d9e663 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
#3  0xb7d91165 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#4  0xb7d91798 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#5  0xb7da1a6c in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#6  0xb7da3238 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#7  0xb7da3589 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#8  0xb7abbbd1 in gtk_widget_realize () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb7abbd8f in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7ac5655 in gtk_window_reshow_with_initial_size () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb7d9e663 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
#12 0xb7d91165 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#13 0xb7d91798 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#14 0xb7da1a6c in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#15 0xb7da3238 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#16 0xb7da3589 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#17 0xb7abbd30 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb7ac783e in gtk_window_get_position () from /usr/lib/libgtk-x11-2.0.so.0
#19 0xb7d9e663 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
#20 0xb7d91165 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#21 0xb7d91798 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#22 0xb7da1a6c in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0
#23 0xb7da3238 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#24 0xb7da3589 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#25 0xb7abc4c6 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#26 0xb794c145 in gtk_container_get_focus_hadjustment () from /usr/lib/libgtk-x11-2.0.so.0
#27 0xb7ab4fb7 in gtk_widget_show_all () from /usr/lib/libgtk-x11-2.0.so.0
#28 0xb7beee96 in init_gtk () from /usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so
#29 0x080b5be9 in PyEval_EvalFrame ()
#30 0x080b739f in PyEval_EvalCodeEx ()
#31 0x080b75e5 in PyEval_EvalCode ()
#32 0x080d908c in PyRun_FileExFlags ()
#33 0x080d932c in PyRun_SimpleFileExFlags ()
#34 0x08055b03 in Py_Main ()
#35 0xb7e86ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#36 0x08054f71 in _start ()
(gdb)

Comment 1

[Christian Persch (GNOME) (away; not receiving bug mail)]

Since the crash is not 100% reproducible, have you tried valgrinding it?

Comment 2

[Ian Jackson]

Yes, sorry for not mentioning it.  I did try valgrind and that didn't spot the problem until the crash.  (I did find an unrelated UMR and of course there were the usual complaints about ld.so and Xlib.)

Comment 3

[Steve Castellotti]

Background information, just posted this to the Ubuntu bug tracker forum listed  in the initial bug report above. The problem I am investigating revolves around the Python gtkmozembed module.

The problem appears to be related to differences between Firefox and Seamonkey.

I've been tracking this bug across other distributions, including Fedora 7 and CentOS 5 and can confirm the issue is not specific to Unbuntu. The Segmentation Fault occurs when a "show_all" call is made to a parent window (such as "self.parent.show_all()")

The F7 release of gnome-python2-gtkmozembed (equivalent to the Ubuntu package in question) shows the python module itself being linked to the firefox libraries:

ldd /usr/lib/python2.5/site-packages/gtk-2.0/gtkmozembed.so | grep fire

libgtkembedmoz.so => /usr/lib/firefox-2.0.0.5/libgtkembedmoz.so (0x00be5000)
libxpcom.so => /usr/lib/firefox-2.0.0.5/libxpcom.so (0x00ce5000)
libxpcom_core.so => /usr/lib/firefox-2.0.0.5/libxpcom_core.so (0x00e63000)

If you install the "seamonkey" package and simply swap paths temporarily:

mv /usr/lib/firefox-2.0.0.5 /usr/lib/firefox-2.0.0.5.off
ln -s /usr/lib/seamokey-1.1.3 /usr/lib/firefox-2.0.0.5

The same code will work immediately. Python therefore needs its gtkmozembed module compiled against seamonkey, not firefox, in order to work.

If sample code would be of use I would be happy to oblige.

Cheers

Comment 4

[timeless]

i don't recognize show_all. is it possible for you to instrument the gtkmozembed sources/binary to for function entry/exit for both seamonkey and firefox (you can use dtrace, fprintf, debugbreakpoints set to log+continue) and compare outputs between working and not working?

Comment 5

[Steve Castellotti]

I'd be happy to help debug if you can walk me through what you need.

Bearing in mind I'm working via the python module here, I'm not sure I would have access to stuff like dtrace and fprintf unless I re-coded my application in C?

In any case the show_all call is to GTK, do a page search for a blurb on the Python GTKMozEmbed module class reference at this URL:

http://www.pygtk.org/pygtkmozembed/class-gtkmozembed.html

Comment 6

[Christian Persch (GNOME) (away; not receiving bug mail)]

Does the crash still happen if you
export LD_LIBRARY_PATH=/usr/lib/firefox-2.0.0.5
export MOZILLA_FIVE_HOME=/usr/lib/firefox-2.0.0.5
before launching your test programme ?

Comment 7

[Steve Castellotti]

Bingo.

I had already set LD_LIBRARY_PATH via /etc/ld.so.conf.d

It was MOZILLA_FIVE_HOME which made the difference.

Does this come down to an error in the package configuration or someone else in the distribution perhaps? Happy to report the issue upstream if I know where it belongs.


FYI here's a simplified test case:


#!/usr/bin/env python
import gtk
import gtkmozembed

window = gtk.Window()
module = gtkmozembed.MozEmbed()

window.add(module)
window.show_all()

Comment 8

[Reed Loden [:reed]]

Is this still a problem with Firefox 3 / Gecko 1.9?

Comment 9

[Lev Shamardin]

Yes, this is still a problem with Firefox 3. In my case the bug is confirmed on both Fedora 8 (firefox-2.0.0.14) and Fedora 9 (firefox-3.0-0.60.beta5).

Comment 10

[Jani Ollikainen]

Well, Don't know who's fault it is, but those enviroments will make the difference. Reason for not working for Fedora 9 is that the xulrunner is it's own package and the needed libs lie in /usr/lib/xulrunner*

https://bugzilla.redhat.com/show_bug.cgi?id=439667

Comment 11

[timeless]

read your distro's docs for installing symbols.

it'll probably be easier for you to use gdb than printf, it's merely about what you're comfortable w/. using printf would involve recompiling either gtkmozembed or gecko after inserting the printfs into whichever. using breakpoints just means you'll have to reset them when you restart.

you have a couple of choices wrt when you attach gdb:
0. run python directly from gdb
1. attach before import gtkmozembed
2. attach before module = gtkmozembed.MozEmbed()
3. attach before window.show_all()

personally, i'd probably use 0 for a while. but basically you set breakpoints on things and try to figure out where things go wrong.

Comment 12

[Robert Kaiser]

AFAIK, GTK embedding in that way has been discontinued, and future embedding efforts will likely go different ways, so this bug is probably not relevant any more.
That said, there's no info here on any recent software versions and code responsible for that probably has changed a lot. If this is still relevant, please reopen with current info and a crash signature.