** Changed in: firefox
Status: Confirmed = Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/26436
Title:
gtkmozembed crashs with python
To manage notifications about this bug
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
steve ... since xul 1.9 that shouldnt be needed anymore. things are
happening automagically.
--
gtkmozembed crashs with python
https://bugs.launchpad.net/bugs/26436
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing
well ... except when you use your own gtkmozembed stuff ... or the
debian one. ubuntu packages should be fine.
--
gtkmozembed crashs with python
https://bugs.launchpad.net/bugs/26436
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
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
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
On Sun, Jan 13, 2008 at 08:37:26PM -, 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
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
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 (Ubuntu)
Status: In Progress = Won't Fix
--
gtkmozembed crashs with python
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
On Sun, Jul 22, 2007 at 07:09:41AM -, 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,
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
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:
2007/7/22, Steve Castellotti [EMAIL PROTECTED]:
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
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
2007/7/22, Steve Castellotti [EMAIL PROTECTED]:
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
--
gtkmozembed
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
on track upstream - In Progress for Ubuntu target.
** Changed in: firefox (Ubuntu)
Assignee: Ian Jackson = Mozilla Bugs
Status: Confirmed = In Progress
--
gtkmozembed crashs with python
https://bugs.launchpad.net/bugs/26436
You received this bug notification because you are a member
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
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
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.
On Wed, May 02, 2007 at 11:04:09AM -, 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
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
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
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.
--
gtkmozembed crashs with
On Tue, May 01, 2007 at 04:22:37PM -, 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
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.
--
gtkmozembed crashs with python
The bug is still present in feisty.
The LD_LIBRARY_PATH trick seems to work
--
gtkmozembed crashs with python
https://bugs.launchpad.net/bugs/26436
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
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
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
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.
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
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
It's been around quite a while, now. Any updates on fixing the problem ?
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
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
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing
python-gtkmozembed in Edgy still Segmentation fault.
still need export LD_LIBRARY_PATH=/usr/lib/firefox
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
what's the status of this bug? any updates?
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Also I tried the following
[EMAIL PROTECTED]:~$ MOZILLA_HOME=/usr/lib/firefox
[EMAIL PROTECTED]:~$ export MOZILLA_HOME
[EMAIL PROTECTED]:~$
[EMAIL PROTECTED]:~$ MOZILLA_FIVE_HOME=/usr/lib/firefox
[EMAIL PROTECTED]:~$ export MOZILLA_FIVE_HOME
[EMAIL PROTECTED]:~$
[EMAIL PROTECTED]:~$
the edgy package is built against firefox not xulrunner and the issue is
still happening with it
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
** Bug 52447 has been marked a duplicate of this bug
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
The problem appears to be gone with gnome-python-extras 2.14.2 compiled
against xulrunner in ubuntu edgy.
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
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?
--
gtkmozembed crashs with python
https://launchpad.net/bugs/26436
--
ubuntu-bugs mailing list
41 matches
Mail list logo
