Ubuntu

gtkmozembed crashs with python

Reported by Michael Vogt on 2005-12-01
82
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Expired
Critical
firefox (Ubuntu)
Medium
Mozilla Bugs
xulrunner-1.9 (Ubuntu)
Undecided
Unassigned

Bug Description

With the upgrade to 1.4.99+1.5rc3.dfsg-1ubuntu3 python applications that embed
firefox with gtkembedmoz (through "python-gnome2-extras") crash. I'll attach a
testapplication and a backtrace (produced with a debug build of ff).

Michael Vogt (mvo) wrote :

Created an attachment (id=5119)
test python app that crashs (need python-gnome2-extras)

This test works with 1.0.7

Michael Vogt (mvo) wrote :

Created an attachment (id=5120)
backtrace of the crash

Michael Vogt (mvo) wrote : c-testcase

a c-testcase to reproduce the problem.

Michael Vogt (mvo) wrote :

The c-testcase works for most people.

Download full text (4.0 KiB)

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 0xb7da1a...

Read more...

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

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.)

Qball Cow (qball-qballcow) wrote :

I am having exactly the same program.
I wrote a plugin for gmpc (0.13, not yet in dapper)
and in the plugin it crashes @ gtk_moz_embed_new()
while the example code above works fine.

Also in python I cannot get it to work. (and alot of programs using it)

Qball Cow (qball-qballcow) wrote :

It seems to crash the moment the moz_embed widget is added (or a container it's in) to a visible window.

For some reason gdb still reports the error in gtk_moz_embed_new
Maybe it internally creates a new window? and therefor is related to #22487? (just guessing here)

I've ran the python program through python, as it shows in the valgrind logs, it tries to read data from a NULL pointer.

==27912== Process terminating with default action of signal 11 (SIGSEGV)
==27912== Access not within mapped region at address 0x0

I get exactly the same error back when I run my (crashing) C program through valgind.

I hope this helps.

Alexandre Otto Strube (surak) wrote :

Michael and Qball have the same issue, so I'm confirming it for bug triage.

Changed in firefox:
status: Unconfirmed → Confirmed

I can confirm it too.

A really simple python app that has only a single gtkmozembed widget
plus a few others works fine in breezy, but crasches on loadurl() in
dapper.

Ian Jackson (ijackson) wrote :

Alexandre Otto Strube writes ("[Bug 26436] gtkmozembed crashs with python"):
> Michael and Qball have the same issue, so I'm confirming it for bug
> triage.

Just for reference, since I seem to have forgotten to write it down
here in the bug report:

I reproduced this bug at the Docklands Dapper sprint but wasn't able
to fix it without spending an unreasonable amount of time on it. So I
reported it upstream, at:
 https://bugzilla.mozilla.org/show_bug.cgi?id=325884

If someone can reproduced it with a non-Ubuntu build (I haven't tried,
personally) then it would be nice if that person would confirm my
upstream report :-).

Thanks,
Ian.

David Planella (dpm) wrote :

I do not know if this comment will help on this issue, but I had been using an application called newton desktop wiki on Breezy (http://newton.sourceforge.net/), which does not work on Dapper anymore. Neither using the .deb package provided from the home page nor compiling the latest svn code fixes the problem (the code compiles fine, the app always crashes on startup).

Having had a look at the newton user's mailing lists, this bug was pointed out to be the cause of the problem (newton apparently uses gtkembedmoz).

I just thought I'd point this out since:

a) maybe this app can be used as a test case for debuggging?

b) someone on the mentioned user's list reported that he was not having this issue in Debian SID, so it could be that it is an Ubuntu-specific one. So far, I haven't seen anyone else confirming this bug upstream in other distros (or indeed much activity since last February).

Dennis Kaarsemaker (dennis) wrote :

The bug is that it does not look in /usr/lib/firefox. Setting LD_LIBRARY_PATH to that value stops my programs from crashing. This should be an easy fix.

Dennis Kaarsemaker (dennis) wrote :

This seems to be the culprit:

dennis@mirage:~/temp/gnome-python-extras-2.14.0$ ldd /usr/lib/firefox/components/libembedcomponents.so
        linux-gate.so.1 => (0xffffe000)
        libgkgfx.so => not found
        libxpcom.so => not found
        libxpcom_core.so => not found
        libplds4.so => /usr/lib/libplds4.so (0xb7ef3000)
        libplc4.so => /usr/lib/libplc4.so (0xb7eee000)
        libnspr4.so => /usr/lib/libnspr4.so (0xb7ebe000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7eab000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ea8000)
        libmozjs.so => not found
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7dd3000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7db1000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7da7000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c77000)
        /lib/ld-linux.so.2 (0x80000000)

Ian Jackson (ijackson) wrote :

Dennis, what makes you say LD_LIBRARY_PATH fixes it ?

Looking at the sample `c-testcase' provided my Michael Vogt (http://librarian.launchpad.net/1547312/pymoz.c) it already uses -Wl,-rpath to set the resulting executable's library search path to include /usr/lib/firefox and nowadays the firefox-gtkmozembed pc file does the same.

> Dennis, what makes you say LD_LIBRARY_PATH fixes it ?

Crack, probably

> Looking at the sample `c-testcase' provided my Michael Vogt
> (http://librarian.launchpad.net/1547312/pymoz.c) it already uses
> -Wl,-rpath to set the resulting executable's library search path to
> include /usr/lib/firefox and nowadays the firefox-gtkmozembed pc file
> does the same.

My system must have been flaky. Yesterday I could fully reproduce
bugs/solutions this way and today I cannot. Sorry for wasting your time.

mcarlson (mcarlson) wrote :

My guess is that this bug started when someone fixed mozilla bug [URL = "https://bugzilla.mozilla.org/show_bug.cgi?id=299988"]299988[/URL] to use libxul/xulrunner.

This seems to have made some changes to the API, not sure what effects that had on this bug if any.

Is it possible to compile a library from the CVS prior to that change to check (I'm not setup to compile mozilla src) this theory? If nothing else this might give a useable version of the library as a stop gap measure.

Tim Fisken (tim2) wrote :

Setting LD_LIBRARY_PATH=/usr/lib/firefox fixes the problem for me, too. I'm using an up-to-date Dapper; attempting to run the python test above segfaults in EmbedPrivate::Realize, according to gdb. It runs fine if I set LD_LIBRARY_PATH. According to locate, I only have one version of libgtkembedmoz.so installed, in /usr/lib/firefox.

At first, gdb was reporting the crash in gtk_moz_embed_get_title (as in the trace linked above), but after I installed firefox-dbg, gdb started reporting the crash as in EmbedPrivate::Realize .

An attempt to run the test app above, with firefox-dgb installed.

David Planella (dpm) wrote :

Executing the python application I was referring to on my last post as follows:

  export LD_LIBRARY_PATH=/usr/lib/firefox && newton

also seems to solve the problem on my system.

Stuart Langridge (sil) wrote :

Confirm that LD_LIBRARY_PATH fixes it in Dapper:

aquarius@giles:~/Projects/jackfield$ python -c "import gtk, gtkmozembed; w = gtk.Window(); w.add(gtkmozembed.MozEmbed()); w.show_all()" Segmentation fault
aquarius@giles:~/Projects/jackfield$ LD_LIBRARY_PATH=/usr/lib/firefox python -c "import gtk, gtkmozembed; w = gtk.Window(); w.add(gtkmozembed.MozEmbed()); w.show_all()"
aquarius@giles:~/Projects/jackfield$

Walla Koala (wallakoala) wrote :

I can also confirm this, and it is very annoying.

Reset Reboot (reset-reboot) wrote :

And here is one more confirmation: export LD_LIBRARY_PATH=/usr/lib/firefox fixes this problem.

¿Maybe it's missing from Breezy?

¿Maybe there's a library in the wrong place?

Gustavo Carneiro (gjc) wrote :

The problem appears to be gone with gnome-python-extras 2.14.2 compiled against xulrunner in ubuntu edgy.

Sebastien Bacher (seb128) wrote :

the edgy package is built against firefox not xulrunner and the issue is still happening with it

Emmanuel Pinault (seatmanu) wrote :

manu@Ruby:~$ python -c "import gtk, gtkmozembed; w = gtk.Window(); w.add(gtkmozembed.MozEmbed()); w.show_all()"
Segmentation fault

I still get a segmentation fault and on Dapper. Crashes with Both Python or Ruby by the way..... and setting my LD_LIBRARY_PATH=/usr/lib/firefox does not seem to help

 ldd /usr/lib/firefox/libgtkembedmoz.so
        linux-gate.so.1 => (0xffffe000)
        libxpcom.so => /usr/lib/firefox/libxpcom.so (0xb7f32000)
        libxpcom_core.so => /usr/lib/firefox/libxpcom_core.so (0xb7e97000)
        libplds4.so => /usr/lib/libplds4.so (0xb7e84000)
        libplc4.so => /usr/lib/libplc4.so (0xb7e7f000)
        libnspr4.so => /usr/lib/libnspr4.so (0xb7e4f000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e3d000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e39000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7b64000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb7ae7000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7ace000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb7ab9000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb7ab1000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7a82000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb7a75000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7a6d000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7a6a000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb7a62000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb7a5f000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7a55000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb7a51000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7a19000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb79d3000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb78ed000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb78b5000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb78b1000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb782d000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb780b000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7736000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb772c000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb75fd000)
        /lib/ld-linux.so.2 (0x80000000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb75d8000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb756f000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb755b000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb753c000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb7538000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7515000)

Emmanuel Pinault (seatmanu) wrote :

Also I tried the following

manu@Ruby:~$ MOZILLA_HOME=/usr/lib/firefox
manu@Ruby:~$ export MOZILLA_HOME
manu@Ruby:~$
manu@Ruby:~$ MOZILLA_FIVE_HOME=/usr/lib/firefox
manu@Ruby:~$ export MOZILLA_FIVE_HOME
manu@Ruby:~$
manu@Ruby:~$ LD_LIBRARY_PATH="/usr/lib/firefox:$LD_LIBRARY_PATH"
manu@Ruby:~$ export LD_LIBRARY_PATH

I tried the demo from ruby ((=> this is the demo from http://ruby-gnome2.sourceforge.jp/hiki.cgi?RubyGecko )

manu@Ruby:~$ ruby moz-editor.rb
ruby: symbol lookup error: /usr/lib/firefox/components/libdocshell.so: undefined symbol: PR_GetPhysicalMemorySize

 and the previous command with python does not doe anything anymore... but no output either

Loell Anthony Erecre (loell) wrote :

what's the status of this bug? any updates?

Jiahua Huang (huangjiahua) wrote :

python-gtkmozembed in Edgy still Segmentation fault.

still need export LD_LIBRARY_PATH="/usr/lib/firefox"

kbg (kbg) wrote :

BTW: Instead of exporting LD_LIBRARY_PATH all the time, you can solve the problem globally by adding the firefox path to the library search path:

  echo "/usr/lib/firefox" >> /etc/ld.so.conf && /sbin/ldconfig

François Feugeas (defraagh) wrote :

It's been around quite a while, now. Any updates on fixing the problem ?

Elliott Hughes (enh) wrote :

on edgy, i have the same problem. running the test case above, LD_LIBRARY_PATH=/usr/lib/firefox appears to be a work-around for me too.

Elliott Hughes (enh) wrote :

spoke too soon: though LD_LIBRARY_PATH=/usr/lib/firefox worked for the test case above, it doesn't seem to work in general. if i modify the test case to use render_data instead of load_url, for example, i get the core dump.

interestingly, my crash seems to be here:

 #0 0xb714f037 in gtk_moz_embed_get_title ()
    from /usr/lib/firefox/libgtkembedmoz.so
 Dump of assembler code from 0xb714f037 to 0xb714f057:
 0xb714f037 <gtk_moz_embed_get_title+4071>: mov (%eax),%edx
 0xb714f039 <gtk_moz_embed_get_title+4073>: movl $0x0,0x4(%esp)
 0xb714f041 <gtk_moz_embed_get_title+4081>: mov %eax,(%esp)
 0xb714f044 <gtk_moz_embed_get_title+4084>: call *0xec(%edx)
 0xb714f04a <gtk_moz_embed_get_title+4090>: mov %eax,(%esp)
 0xb714f04d <gtk_moz_embed_get_title+4093>: call 0xb714b860 <gdk_window_get_parent@plt>
 0xb714f052 <gtk_moz_embed_get_title+4098>: lea 0xffffffdc(%ebp),%edx
 0xb714f055 <gtk_moz_embed_get_title+4101>: movl $0x0,0xffffffdc(%ebp)
 End of assembler dump.

noticing the call to gdk_window_get_parent, if i modify my code to ensure that my MozEmbed is parented before i invoke any methods on it, my program becomes crash-proof. (touch wood!)

this seems not to correspond to where others above claim to have been crashing, but it certainly seems to be where i always crash on edgy/firefox 2.0.0.1.

(i notice there are a lot of crashes out there in gtk_moz_embed_get_title, judging by Google.)

Elliott Hughes (enh) wrote :

Owen Williams mailed me for clarification of my comment above:

1. What changes did you have to make to ensure that it is parented?

basically, you have to ensure that between the "moz = gtkmozembed.MozEmbed()" call to create your MozEmbed, and your first invocation of any method (load_url or render_data or whatever), you've called "some_component.add(moz)". i've also been careful to invoke "show_all()" on a parent before invoking anything on "moz" too, but i'm not sure that's strictly necessary.

2. Also, does this change mean you don't have to do LD_LIBRARY_PATH, or do you have to do it also?

as far as i know, the LD_LIBRARY_PATH is a red herring (or a different bug that i haven't run into).

 --elliott

I have been hunting this bug yesterday. It annoyed me I haven't been able to use Newton Desktop Wiki since I started using Dapper.

The Python script above reproduced the problem for me and I used this to test my solutions. Setting LD_LIBRARY_PATH to /usr/lib/firefox as is mentioned by some above and in other places did work.

gtkmozembed.so provided by python-gnome2-extras already has an RPATH set to /usr/lib/firefox, so it does not help this library. But /usr/lib/firefox/libgtkembedmoz.so has no such RPATH set.

My theory is that the crash is due to some dynamic loading of libraries by the component. Python loads gtkmozembed.so, which loads libgtkembedmoz.so which (I think) tries to load some additional libs that reside in /usr/lib/firefox. It cannot find these, because they are not in the linker's search path. Due to some missing or broken error handling, this results in a crash instead of a friendly error message. This is my theory.

I tested this by compiling Firefox (and therefore libgtkembedmoz.so) with RPATH set. This resulted in a working test case. Good. The attached patch fixes the Firefox package.

In Debian Policy RPATH is frowned upon. I don't know if this is the same in Ubuntu. Seeing that gnome-python-extras uses RPATH, I think not. But it can be a one off error. In that case, the same problem can also be solved by creating a file /etc/ld.so.conf.d/firefox.conf with /usr/lib/firefox as contents. (Run ldconfig after that.)

A good work-around while this isn't fixed is adding /usr/lib/firefox to /etc/ld.so.conf and running ldconfig.

It is interesting to note that xulrunner puts libgtkembedmoz.so and friends in /usr/lib, thereby bypassing this whole issue.

I hope this bug can be fixed before Feisty, since I would really, really like to be able to use Newton out of the box again.

I think Elliott's bug is a different one.

Vosilij Pupkin (dammage) wrote :

The bug is still present in feisty.
The LD_LIBRARY_PATH trick seems to work

Boris Sukholitko (boriss) wrote :

I've had a similar problem as well (ldconfig wasn't helping).

I've resolved the problem by moving aside /usr/lib/firefox/components/compreg.dat. The file has been regenerated by Firefox and everything is working as it should since then.

I am using edgy.

Problem still exists on Feisty Fawn (this is an amd64 machine; previous machine was i386). The ld.so.conf work-around mentioned above still works (for the Python test case and for Newton Desktop Wiki). I didn't test the RPATH fixes, but I suppose they should still work as well.

Boris, I wanted to try your fix, but I don't have the file /usr/lib/firefox/components/compreg.dat. The only compreg.dat on my system exists in my personal profile in my home directory. Removing that doesn't seem to achieve any effect. Is this the same bug?

Is anybody working on this problem, or is the GTK Mozilla component a lost cause for Python+Ubuntu?

Thomas Liebetraut (tommie-lie) wrote :

I'm running Feisty, too (on a x86), and the ld.so.conf workaround works for mee, too.
Other than Sjoerd, I do have /usr/lib/firefox/components/compreg.dat but removing it does not solve the problem.

Thanks, Sjoerd, for providing the ld.so.config workaround, it works fine and makes newton usable again.

Alberto Ruiz (alberto.ruiz) wrote :

Why don't we add /usr/lib/firefox to the ld.so.conf right after install the firefox (or python-gtkmozembed) package? Does anyone has found any other way to fix the problem?

If not, we should provide this workaround, otherwise, the package will be broken by default.

On Tue, May 01, 2007 at 04:22:37PM -0000, aruiz wrote:
> Why don't we add /usr/lib/firefox to the ld.so.conf right after install
> the firefox (or python-gtkmozembed) package? Does anyone has found any
> other way to fix the problem?
>
> If not, we should provide this workaround, otherwise, the package will
> be broken by default.

I think the most natural thing would be to fix this on
python-gtkmozembed side for now. rpath sounds good. ld.so.conf might
interfere with other gecko apps that ship their own gecko libs.

 - Alexander

On Tuesday 01 May 2007, Alexander Sack wrote:
> I think the most natural thing would be to fix this on
> python-gtkmozembed side for now. rpath sounds good. ld.so.conf might
> interfere with other gecko apps that ship their own gecko libs.

The rpath fix would need to be applied to Firefox. python-gtkmozembed
(python-gnome2-extras) already has the rpath set to contain /usr/lib/firefox.
I'm not sure if this will cause problems for other packages.

If the ld.so.conf work-around is considered, I would suggest
using /etc/ld.so.conf.d/. This will make uninstallation of the package less
of a nightmare.

It is of note that /usr/lib/mozilla-thunderbird/run-mozilla.sh
and /usr/lib/firefox/firefox both set the LD_LIBRARY_PATH to contain their
respective "mozilla library directories". Adding the ld.so.conf(.d) work
around might not have as big an impact as we fear, but I do believe other
alternatives might be better; if we have any.

For applications that live in the gnome panel LD_LIBRARY_PATH is not an
option.

How do other distributions solve this problem with Firefox and
python-gtkmozembed? I imagine that Debian's Iceweasel has similar problems.

--
Sjoerd

Alexander Sack (asac) wrote :

On Wed, May 02, 2007 at 11:04:09AM -0000, Sjoerd Hemminga wrote:
> On Tuesday 01 May 2007, Alexander Sack wrote:
> > I think the most natural thing would be to fix this on
> > python-gtkmozembed side for now. rpath sounds good. ld.so.conf might
> > interfere with other gecko apps that ship their own gecko libs.
>
> The rpath fix would need to be applied to Firefox. python-gtkmozembed
> (python-gnome2-extras) already has the rpath set to contain /usr/lib/firefox.
> I'm not sure if this will cause problems for other packages.
>

why rpath on firefox side? why not on python?

 - Alexander

On Wednesday 02 May 2007, Alexander Sack wrote:
> > The rpath fix would need to be applied to Firefox. python-gtkmozembed
> > (python-gnome2-extras) already has the rpath set to contain
> > /usr/lib/firefox. I'm not sure if this will cause problems for other
> > packages.
> why rpath on firefox side? why not on python?

The gtkmozembed component already has its rpath set and it doesn't work.
Setting the rpath on the python executable might work; I haven't tried this.
I lack knowledge about the resolve mechanisms of the run-time linker to judge
this.

--
Sjoerd

Alexander Sack (asac) wrote :

on track upstream -> In Progress for Ubuntu target.

Changed in firefox:
assignee: ijackson → mozilla-bugs
status: Confirmed → In Progress

I just reread this bug report. It seems to me there really are two bugs here. The bug that is reported upstream is definitely not the bug I, and apparently others, are experiencing. The C test worked, while the Python version is consistently not working. The LD_LIBRARY_PATH work around works for some while others report it non-working.

I'm not sure which bug the reporter was experiencing, but if I had to wager a guess, it would not be the LD_LIBRARY_PATH bug. I think this bug report needs to be split. (Is something like that possible?)

encompass (encompass) wrote :

I thought this bug had the segfault only on Show... but am I wrong? Because my aplication I am making, pystart, I just didn't show the widget. But now it is not show... but gives a segfault anyway. Interesting indeed! the program is here... http://launchpad.net/pystart/ trunk revision 45. :) Feel free!

The problem appears to be related to difference between Firefox and Seamonkey (originally known as "Mozilla").

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

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 (the new name for the mozilla project is "seamonkey" so we're really just talking about the original software from the mozilla project) 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 code will work immediately. Python therefore needs its gtkmozembed module compiled against seamonkey, not firefox, in order to work.

You may or may not still need the LD_LIBRARY_PATH export (I don't have an Ubuntu box to verify) but my guess is you won't.

Best of luck.

Cheers

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

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?

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

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 ?

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()

Quick followup:

Besides the LD_LIBRARY_PATH you need to set the MOZILLA_FIVE_HOME environment variable, for example:

export MOZILLA_FIVE_HOME=/usr/lib/firefox-2.0.0.5

for more details please refer to the Mozilla bug report indicated earlier in this thread:

https://bugzilla.mozilla.org/show_bug.cgi?id=325884

2007/7/22, Steve Castellotti <email address hidden>:
> Quick followup:
>
> Besides the LD_LIBRARY_PATH you need to set the MOZILLA_FIVE_HOME
> environment variable, for example:
>
> export MOZILLA_FIVE_HOME=/usr/lib/firefox-2.0.0.5
>
>

Wouldn't be better to link gtkmozembed against firefox by default?

> for more details please refer to the Mozilla bug report indicated earlier in this thread:
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=325884
>
> --
> gtkmozembed crashs with python
> https://bugs.launchpad.net/bugs/26436
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Un saludo,
Alberto Ruiz

> Wouldn't be better to link gtkmozembed against firefox by default?

That's not the issue. On my machine (Fedora 7) the python module *is* linked against the firefox version of libgtkembedmoz.so - its only when you swap the seamonkey version into the same path that the code works.

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 (0x0011a000)
        libxpcom.so => /usr/lib/firefox-2.0.0.5/libxpcom.so (0x00139000)
        libxpcom_core.so => /usr/lib/firefox-2.0.0.5/libxpcom_core.so (0x0094a000)

Another solution is to define MOZILLA_FIVE_HOME, as that doesn't require swapping system files around.

Either solution works however.

Alberto Ruiz (alberto.ruiz) wrote :

2007/7/22, Steve Castellotti <email address hidden>:
>
> Another solution is to define MOZILLA_FIVE_HOME, as that doesn't require swapping system files around.
>

would be possible to setup that env variable on the gtkmozembed module
before to load the .so?

--
Un saludo,
Alberto Ruiz

Alexander Sack (asac) wrote :

On Sun, Jul 22, 2007 at 07:09:41AM -0000, Steve Castellotti wrote:
>
> 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 code will work immediately. Python therefore needs its gtkmozembed module compiled against seamonkey, not firefox, in order to work.
>

Does FC install any mozilla libs in /usr/lib ?

 - Alexander

plun (plun) wrote :

More info, work around for Gutsy Gibbon

export LD_LIBRARY_PATH=/usr/lib/firefox

export MOZILLA_FIVE_HOME=/usr/lib/firefox

Reference
https://bugzilla.mozilla.org/show_bug.cgi?id=325884

New application which uses gtkmozembed is Screenlets

http://forum.compiz-fusion.org/forumdisplay.php?f=102

UF thread:
http://ubuntuforums.org/showthread.php?t=547969

Alexander Sack (asac) wrote :

this won't be fixed in firefox 2 ... xulrunner-1.9 provides glue that should load the right libs automagically. If it doesn't work using xulrunner-1.9 please add the appropriate bug target.

Changed in firefox:
status: In Progress → Won't Fix
ddfelts (dan-felts) wrote :

I have been testing this and found a rather funny issue.

Although the work around works it appears that the python binding seg faults if you try and access a https sight. So thinking that this same issue should affect the ruby binding to a certain extent I decided to check. The ruby binding when trying to access the same https sight (gmail) for example, actually produces a message box where the python binding doesn't. Just some food for thought.

Dan

Alexander Sack (asac) wrote :

On Sun, Jan 13, 2008 at 08:37:26PM -0000, ddfelts wrote:
> I have been testing this and found a rather funny issue.
>
> Although the work around works it appears that the python binding seg
> faults if you try and access a https sight. So thinking that this same
> issue should affect the ruby binding to a certain extent I decided to
> check. The ruby binding when trying to access the same https sight
> (gmail) for example, actually produces a message box where the python
> binding doesn't. Just some food for thought.

this was fixed by the xulrunner-1.9 transition in hardy ...

 affects ubuntu/xulrunner-1.9
 status fixreleased

 - Alexander

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

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).

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

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.

Hi there,

I had a similar error: gtkmozembed hung the whole application, when accessing certain sites with flash-animations.
After almost a day, the following line found to be absolute incompatible with gtkmozembed and flash:
gtk.gdk.threads_init()
Seems to be a threading problem: This line was garbage in my Script and did not have any purpose. My fault, but kind of strange...

After all: Threading and gtkmozembed work, when no flash plugin is installed for firefox.

Hope, this is useful for someone.

The following two lines of code should safely sort any gtkmozembed python program when running with xul-runner. It should not be necessary to modify any environment variables such as MOZILLA_HOME_FIVE, MOZILLA_HOME, or LD_LIBRARY_PATH - although obviously it the example path only works for the indicated version of xul-runner:

if os.path.exists('/usr/lib/xulrunner-1.9'):
 gtkmozembed.set_comp_path('/usr/lib/xulrunner-1.9')

That should be all that is necessary, and it should still be safe to execute on legacy systems.

I run it immediately after importing the gtkmozembed module, prior to displaying the main window.

And just FYI, I've never ran into problems with multi-threaded gtkmozembed components when displaying Flash.

Alexander Sack (asac) wrote :

steve ... since xul 1.9 that shouldnt be needed anymore. things are happening automagically.

Alexander Sack (asac) wrote :

well ... except when you use your own gtkmozembed stuff ... or the debian one. ubuntu packages should be fine.

Changed in firefox:
importance: Unknown → Critical
scytlae (scytale-gmail) wrote :
Download full text (3.2 KiB)

i'm still seeing a segfault when using gtkmozembed - i'm not sure if it's the same bug - the backtrace looks different.
let me know if it looks sufficiently different to warrant a new bug.
let me know if you want further data from gdb/valgrind or whatever.

setting LD_LIBRARY_PATH or MOZILLA_FIVE_HOME has no effect.
neither does the adding the line "gtkmozembed.set_comp_path('/usr/lib/xulrunner-1.9.2.13')" to my script
i tried removing /usr/lib/xulrunner-1.9.2.13/components/compreg.dat but that had no effect
according to strace the library is not trying to access the compreg.dat stored in my firefox profile

my test script:

#!/usr/bin/python2.6
import gtkmozembed
data = """<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8" /></head><body></body></html>"""
html_doc = gtkmozembed.MozEmbed()
html_doc.render_data(data, long(len(data)), 'file:///', 'text/html')

backtrace:

#0 EmbedPrivate::OpenStream (this=0x10d6cc0, aBaseURI=0x7f05c00edbf4 "file:///", aContentType=0x7f05c00ee984 "text/html") at EmbedPrivate.cpp:664
#1 0x00007f05b689c03d in gtk_moz_embed_render_data (embed=<value optimized out>, data=
    0x7f05c01626dc "<html><head><meta http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\" /></head><body></body></html>", len=108, base_uri=0x7f05c00edbf4 "file:///", mime_type=
    0x7f05c00ee984 "text/html") at gtkmozembed2.cpp:786
#2 0x00007f05be6ebfad in ?? () from /usr/lib/pymodules/python2.6/gtk-2.0/gtkmozembed.so
#3 0x00000000004a51ae in call_function (f=Frame 0xc352c0, for file ./test.py, line 8, in <module> (), throwflag=<value optimized out>) at ../Python/ceval.c:3750
#4 PyEval_EvalFrameEx (f=Frame 0xc352c0, for file ./test.py, line 8, in <module> (), throwflag=<value optimized out>) at ../Python/ceval.c:2412
#5 0x00000000004a6bd1 in PyEval_EvalCodeEx (co=0x7f05c00dc918, globals=<value optimized out>, locals=<value optimized out>, args=0x0, argcount=<value optimized out>, kws=<value optimized out>,
    kwcount=0, defs=0x0, defcount=0, closure=0x0) at ../Python/ceval.c:3000
#6 0x00000000004a6ca2 in PyEval_EvalCode (co=0x7fffdb9b38d0, globals=<unknown at remote 0x7f05c00edbf4>, locals=<unknown at remote 0x7f05c00ee984>) at ../Python/ceval.c:541
#7 0x00000000004c702e in run_mod (fp=<value optimized out>, filename=0x7fffdb9b4583 "./test.py", start=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>,
    closeit=1, flags=0x7fffdb9b3dc0) at ../Python/pythonrun.c:1351
#8 PyRun_FileExFlags (fp=<value optimized out>, filename=0x7fffdb9b4583 "./test.py", start=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>, closeit=1, flags=
    0x7fffdb9b3dc0) at ../Python/pythonrun.c:1337
#9 0x00000000004c7244 in PyRun_SimpleFileExFlags (fp=<value optimized out>, filename=0x7fffdb9b4583 "./test.py", closeit=1, flags=0x7fffdb9b3dc0) at ../Python/pythonrun.c:941
#10 0x00000000004180c1 in Py_Main (argc=-1072893824, argv=<value optimized out>) at ../Modules/main.c:577
#11 0x00007f05bebbbd8e in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized ...

Read more...

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.

Changed in firefox:
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.