gtkmozembed crashs with python
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Expired
|
Critical
|
|||
firefox (Ubuntu) |
Won't Fix
|
Medium
|
Mozilla Bugs | ||
xulrunner-1.9 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
With the upgrade to 1.4.99+
firefox with gtkembedmoz (through "python-
testapplication and a backtrace (produced with a debug build of ff).
Michael Vogt (mvo) wrote : | #1 |
Michael Vogt (mvo) wrote : | #2 |
- backtrace of the crash Edit (4.0 KiB, text/plain)
Created an attachment (id=5120)
backtrace of the crash
Michael Vogt (mvo) wrote : c-testcase | #3 |
Michael Vogt (mvo) wrote : | #4 |
The c-testcase works for most people.
In Mozilla Bugzilla #325884, Ian Jackson (iwj) wrote : | #5 |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060204 Ubuntu/
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060204 Ubuntu/
https:/
Investigating with a debugger shows that
mWindow-
(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:
Reproducible: Sometimes
Steps to Reproduce:
Program received signal SIGSEGV, Segmentation fault.
0xb72a0fe1 in EmbedPrivate:
280 NS_STATIC_
(gdb) bt
#0 0xb72a0fe1 in EmbedPrivate:
#1 0xb729e9e9 in gtk_moz_
#2 0xb7d9e663 in g_cclosure_
#3 0xb7d91165 in g_cclosure_new_swap () from /usr/lib/
#4 0xb7d91798 in g_closure_invoke () from /usr/lib/
#5 0xb7da1a6c in g_signal_
#6 0xb7da3238 in g_signal_
#7 0xb7da3589 in g_signal_emit () from /usr/lib/
#8 0xb7abbbd1 in gtk_widget_realize () from /usr/lib/
#9 0xb7abbd8f in gtk_widget_map () from /usr/lib/
#10 0xb7ac5655 in gtk_window_
#11 0xb7d9e663 in g_cclosure_
#12 0xb7d91165 in g_cclosure_new_swap () from /usr/lib/
#13 0xb7d91798 in g_closure_invoke () from /usr/lib/
#14 0xb7da1a6c in g_signal_
#15 0xb7da3238 in g_signal_
#16 0xb7da3589 in g_signal_emit () from /usr/lib/
#17 0xb7abbd30 in gtk_widget_map () from /usr/lib/
#18 0xb7ac783e in gtk_window_
#19 0xb7d9e663 in g_cclosure_
#20 0xb7d91165 in g_cclosure_new_swap () from /usr/lib/
#21 0xb7d91798 in g_closure_invoke () from /usr/lib/
#22 0xb7da1a...
In Mozilla Bugzilla #325884, c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote : | #6 |
Since the crash is not 100% reproducible, have you tried valgrinding it?
In Mozilla Bugzilla #325884, Ian Jackson (iwj) wrote : | #7 |
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 : | #8 |
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 : | #9 |
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)
Qball Cow (qball-qballcow) wrote : Valgrind log of crash | #10 |
- Valgrind log of crash Edit (163.0 KiB, text/plain)
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 : | #11 |
Michael and Qball have the same issue, so I'm confirming it for bug triage.
Changed in firefox: | |
status: | Unconfirmed → Confirmed |
Dennis Kaarsemaker (dennis) wrote : Re: [Bug 26436] gtkmozembed crashs with python | #12 |
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 : | #13 |
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:/
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 : | #14 |
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://
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 : | #15 |
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 : | #16 |
This seems to be the culprit:
dennis@
libgkgfx.so => not found
libxpcom.so => not found
libplds4.so => /usr/lib/
libplc4.so => /usr/lib/libplc4.so (0xb7eee000)
libnspr4.so => /usr/lib/
libdl.so.2 => /lib/tls/
libmozjs.so => not found
libm.so.6 => /lib/tls/
libc.so.6 => /lib/tls/
Ian Jackson (ijackson) wrote : | #17 |
Dennis, what makes you say LD_LIBRARY_PATH fixes it ?
Looking at the sample `c-testcase' provided my Michael Vogt (http://
Dennis Kaarsemaker (dennis) wrote : Re: [Bug 26436] Re: gtkmozembed crashs with python | #18 |
> Dennis, what makes you say LD_LIBRARY_PATH fixes it ?
Crack, probably
> Looking at the sample `c-testcase' provided my Michael Vogt
> (http://
> -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 : | #19 |
My guess is that this bug started when someone fixed mozilla bug [URL = "https:/
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 : | #20 |
Setting LD_LIBRARY_
At first, gdb was reporting the crash in gtk_moz_
Tim Fisken (tim2) wrote : Stack trace crashing in EmbedPrivate::Realize | #21 |
- Stack trace crashing in EmbedPrivate::Realize Edit (4.5 KiB, text/plain)
An attempt to run the test app above, with firefox-dgb installed.
David Planella (dpm) wrote : | #22 |
Executing the python application I was referring to on my last post as follows:
export LD_LIBRARY_
also seems to solve the problem on my system.
Stuart Langridge (sil) wrote : | #23 |
Confirm that LD_LIBRARY_PATH fixes it in Dapper:
aquarius@
aquarius@
aquarius@
Walla Koala (wallakoala) wrote : | #24 |
I can also confirm this, and it is very annoying.
Reset Reboot (reset-reboot) wrote : | #25 |
And here is one more confirmation: export LD_LIBRARY_
¿Maybe it's missing from Breezy?
¿Maybe there's a library in the wrong place?
Gustavo Carneiro (gjc) wrote : | #26 |
The problem appears to be gone with gnome-python-extras 2.14.2 compiled against xulrunner in ubuntu edgy.
Sebastien Bacher (seb128) wrote : | #27 |
the edgy package is built against firefox not xulrunner and the issue is still happening with it
Emmanuel Pinault (seatmanu) wrote : | #28 |
manu@Ruby:~$ python -c "import gtk, gtkmozembed; w = gtk.Window(); w.add(gtkmozemb
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_
ldd /usr/lib/
libxpcom.so => /usr/lib/
libplds4.so => /usr/lib/
libplc4.so => /usr/lib/libplc4.so (0xb7e7f000)
libnspr4.so => /usr/lib/
libdl.so.2 => /lib/tls/
libXi.so.6 => /usr/lib/libXi.so.6 (0xb7a62000)
libX11.so.6 => /usr/lib/
libm.so.6 => /lib/tls/
libc.so.6 => /lib/tls/
libz.so.1 => /usr/lib/libz.so.1 (0xb755b000)
libXau.so.6 => /usr/lib/
Emmanuel Pinault (seatmanu) wrote : | #29 |
Also I tried the following
manu@Ruby:~$ MOZILLA_
manu@Ruby:~$ export MOZILLA_HOME
manu@Ruby:~$
manu@Ruby:~$ MOZILLA_
manu@Ruby:~$ export MOZILLA_FIVE_HOME
manu@Ruby:~$
manu@Ruby:~$ LD_LIBRARY_
manu@Ruby:~$ export LD_LIBRARY_PATH
I tried the demo from ruby ((=> this is the demo from http://
manu@Ruby:~$ ruby moz-editor.rb
ruby: symbol lookup error: /usr/lib/
and the previous command with python does not doe anything anymore... but no output either
Loell Anthony Erecre (loell) wrote : | #30 |
what's the status of this bug? any updates?
Jiahua Huang (huangjiahua) wrote : | #31 |
python-gtkmozembed in Edgy still Segmentation fault.
still need export LD_LIBRARY_
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 : | #33 |
It's been around quite a while, now. Any updates on fixing the problem ?
Elliott Hughes (enh) wrote : | #34 |
on edgy, i have the same problem. running the test case above, LD_LIBRARY_
Elliott Hughes (enh) wrote : | #35 |
spoke too soon: though LD_LIBRARY_
interestingly, my crash seems to be here:
#0 0xb714f037 in gtk_moz_
from /usr/lib/
Dump of assembler code from 0xb714f037 to 0xb714f057:
0xb714f037 <gtk_moz_
0xb714f039 <gtk_moz_
0xb714f041 <gtk_moz_
0xb714f044 <gtk_moz_
0xb714f04a <gtk_moz_
0xb714f04d <gtk_moz_
0xb714f052 <gtk_moz_
0xb714f055 <gtk_moz_
End of assembler dump.
noticing the call to gdk_window_
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_
Elliott Hughes (enh) wrote : | #36 |
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.
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
Sjoerd Hemminga (sjoerd-hemminga) wrote : | #37 |
- Firefox patch to set RPATH to /usr/lib/firefox Edit (528 bytes, text/plain)
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-
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.
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 : | #38 |
The bug is still present in feisty.
The LD_LIBRARY_PATH trick seems to work
Boris Sukholitko (boriss) wrote : | #39 |
I've had a similar problem as well (ldconfig wasn't helping).
I've resolved the problem by moving aside /usr/lib/
I am using edgy.
Sjoerd Hemminga (sjoerd-hemminga) wrote : | #40 |
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/
Is anybody working on this problem, or is the GTK Mozilla component a lost cause for Python+Ubuntu?
Thomas Liebetraut (tommie-lie) wrote : | #41 |
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/
Thanks, Sjoerd, for providing the ld.so.config workaround, it works fine and makes newton usable again.
Alberto Ruiz (alberto.ruiz) wrote : | #42 |
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.
Alexander Sack (asac) wrote : Re: [Bug 26436] Re: gtkmozembed crashs with python | #43 |
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
Sjoerd Hemminga (sjoerd-hemminga) wrote : | #44 |
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-
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/
and /usr/lib/
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 : | #45 |
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-
> I'm not sure if this will cause problems for other packages.
>
why rpath on firefox side? why not on python?
- Alexander
Sjoerd Hemminga (sjoerd-hemminga) wrote : | #46 |
On Wednesday 02 May 2007, Alexander Sack wrote:
> > The rpath fix would need to be applied to Firefox. python-gtkmozembed
> > (python-
> > /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 : | #47 |
on track upstream -> In Progress for Ubuntu target.
Changed in firefox: | |
assignee: | ijackson → mozilla-bugs |
status: | Confirmed → In Progress |
Sjoerd Hemminga (sjoerd-hemminga) wrote : | #48 |
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 : | #49 |
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://
Steve Castellotti (steve-theprofessionalamateur) wrote : | #50 |
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.
The F7 release of gnome-python2-
ldd /usr/lib/
libgtkembedmoz.so => /usr/lib/
libxpcom.so => /usr/lib/
libxpcom_core.so => /usr/lib/
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/
ln -s /usr/lib/
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
In Mozilla Bugzilla #325884, Steve Castellotti (steve-theprofessionalamateur) wrote : | #51 |
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.
The F7 release of gnome-python2-
ldd /usr/lib/
libgtkembedmoz.so => /usr/lib/
libxpcom.so => /usr/lib/
libxpcom_core.so => /usr/lib/
If you install the "seamonkey" package and simply swap paths temporarily:
mv /usr/lib/
ln -s /usr/lib/
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
In Mozilla Bugzilla #325884, Timeless-bemail (timeless-bemail) wrote : | #52 |
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?
In Mozilla Bugzilla #325884, Steve Castellotti (steve-theprofessionalamateur) wrote : | #53 |
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:
In Mozilla Bugzilla #325884, c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount) wrote : | #54 |
Does the crash still happen if you
export LD_LIBRARY_
export MOZILLA_
before launching your test programme ?
In Mozilla Bugzilla #325884, Steve Castellotti (steve-theprofessionalamateur) wrote : | #55 |
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.
window.add(module)
window.show_all()
Steve Castellotti (steve-theprofessionalamateur) wrote : | #56 |
Quick followup:
Besides the LD_LIBRARY_PATH you need to set the MOZILLA_FIVE_HOME environment variable, for example:
export MOZILLA_
for more details please refer to the Mozilla bug report indicated earlier in this thread:
Alberto Ruiz (alberto.ruiz) wrote : Re: [Bug 26436] Re: gtkmozembed crashs with python | #57 |
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_
>
>
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:/
>
> --
> gtkmozembed crashs with python
> https:/
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
--
Un saludo,
Alberto Ruiz
Steve Castellotti (steve-theprofessionalamateur) wrote : | #58 |
> 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/
libxpcom.so => /usr/lib/
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 : | #59 |
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 : | #60 |
On Sun, Jul 22, 2007 at 07:09:41AM -0000, Steve Castellotti wrote:
>
> mv /usr/lib/
> ln -s /usr/lib/
>
>
> 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 : | #61 |
More info, work around for Gutsy Gibbon
export LD_LIBRARY_
export MOZILLA_
Reference
https:/
New application which uses gtkmozembed is Screenlets
Alexander Sack (asac) wrote : | #62 |
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 : | #63 |
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 : | #64 |
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/
status fixreleased
- Alexander
In Mozilla Bugzilla #325884, Reed Loden (reed) wrote : | #65 |
Is this still a problem with Firefox 3 / Gecko 1.9?
In Mozilla Bugzilla #325884, abbot (shamardin) wrote : | #66 |
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-
In Mozilla Bugzilla #325884, Bestis+mozilla (bestis+mozilla) wrote : | #67 |
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*
In Mozilla Bugzilla #325884, Timeless-bemail (timeless-bemail) wrote : | #68 |
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.
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.
Daniel Nögel (daniel-xn--ngel-5qa) wrote : | #69 |
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.
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.
Steve Castellotti (steve-theprofessionalamateur) wrote : | #70 |
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.
gtkmozembed.
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 : | #71 |
steve ... since xul 1.9 that shouldnt be needed anymore. things are happening automagically.
Alexander Sack (asac) wrote : | #72 |
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 : | #73 |
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.
i tried removing /usr/lib/
according to strace the library is not trying to access the compreg.dat stored in my firefox profile
my test script:
#!/usr/
import gtkmozembed
data = """<html>
html_doc = gtkmozembed.
html_doc.
backtrace:
#0 EmbedPrivate:
#1 0x00007f05b689c03d in gtk_moz_
0x7f05c01626dc "<html><head><meta http-equiv=
0x7f05c00ee984 "text/html") at gtkmozembed2.
#2 0x00007f05be6ebfad in ?? () from /usr/lib/
#3 0x00000000004a51ae in call_function (f=Frame 0xc352c0, for file ./test.py, line 8, in <module> (), throwflag=<value optimized out>) at ../Python/
#4 PyEval_EvalFrameEx (f=Frame 0xc352c0, for file ./test.py, line 8, in <module> (), throwflag=<value optimized out>) at ../Python/
#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/
#6 0x00000000004a6ca2 in PyEval_EvalCode (co=0x7fffdb9b38d0, globals=<unknown at remote 0x7f05c00edbf4>, locals=<unknown at remote 0x7f05c00ee984>) at ../Python/
#7 0x00000000004c702e in run_mod (fp=<value optimized out>, filename=
closeit=1, flags=0x7fffdb9
#8 PyRun_FileExFlags (fp=<value optimized out>, filename=
0x7fffdb9b3dc0) at ../Python/
#9 0x00000000004c7244 in PyRun_SimpleFil
#10 0x00000000004180c1 in Py_Main (argc=-1072893824, argv=<value optimized out>) at ../Modules/
#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 ...
In Mozilla Bugzilla #325884, Kairo-kairo (kairo-kairo) wrote : | #74 |
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 |
Created an attachment (id=5119) gnome2- extras)
test python app that crashs (need python-
This test works with 1.0.7