After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 513744 - epiphany/xulrunner crashed because of totem plugin
epiphany/xulrunner crashed because of totem plugin
Status: RESOLVED NOTABUG
Product: totem
Classification: Core
Component: Browser plugin (obsolete)
2.21.x
Other All
: High critical
: ---
Assigned To: totem-browser-maint
totem-browser-maint
Depends on:
Blocks:
 
 
Reported: 2008-02-01 18:51 UTC by Jakub 'Livio' Rusinek
Modified: 2008-07-30 14:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Jakub 'Livio' Rusinek 2008-02-01 18:51:24 UTC
Steps to reproduce:
1. download snapshot from trunk
2. open some page, like stage6

Stack trace:


Other information:
No crash report is saved by Firefox neither Totem plugin.
Comment 1 Jakub 'Livio' Rusinek 2008-02-01 18:52:10 UTC
firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=378911
Comment 2 Bastien Nocera 2008-02-04 17:33:26 UTC
The backtrace shows no bits of Totem, and it works fine for me in a slightly older xulrunner-based epiphany. Please post a backtrace with Totem bits showing if you have one, otherwise I'll close this as NOTGNOME.
Comment 3 Jakub 'Livio' Rusinek 2008-02-04 19:04:12 UTC
Test in CURRENT trunk, not OLDER. Even 28hrs matter here.

Currently Firefox crashes, when Totem should load.
Not sure about Epiphany (I should upgrade to Rawhide, or use left built GNOME libs and Epiphany or download GNOME-Trunk LiveCD... it has no sense if I want to have stable system).
Comment 4 Bastien Nocera 2008-02-04 19:06:42 UTC
Please give me a backtrace, otherwise I can't do anything. My point was that it used to work, and if it doesn't anymore, it's Firefox' fault, not ours.
Comment 5 Jakub 'Livio' Rusinek 2008-02-04 19:09:02 UTC
I'm curious how if Totem crashes Firefox and nothing is saved...

Test with CURRENT trunk, not older. Try it yourself and then look yourself it some backtrace is saved, even in about:crashes.

I didn't noticed any.

It cannot be Firefox bug, because stupid Flash works nice.
Comment 6 Bastien Nocera 2008-02-04 19:14:22 UTC
Thanks for taking the time to report this bug.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 7 Jakub 'Livio' Rusinek 2008-02-04 20:34:52 UTC
Cannot get anything because gdb don't like scripts for running programs.
Running firefix-bin directly doesn't work (libxul.so not found).
Comment 8 Bastien Nocera 2008-02-04 20:57:58 UTC
You can attach gdb to firefox using "gdb attach `pidof firefox-bin`", or simply let firefox dump core by running:
unlimit -c unlimited # Enable core dumps
export GNOME_DISABLE_CRASH_DIALOG=1 # Disable the GTK breakpad module

See also:
http://fedoraproject.org/wiki/StackTraces
Comment 9 Jakub 'Livio' Rusinek 2008-02-04 21:52:11 UTC
Firefox hangs when doing gdb attach...
Comment 10 Jakub 'Livio' Rusinek 2008-02-04 21:56:45 UTC
No core dump is saved or I can't find it.

PS: Not 'unlimit' but 'ulimit'.
Comment 11 Jakub 'Livio' Rusinek 2008-02-04 22:00:05 UTC
gdb output: http://wklej.org/id/b951f39b78

still not backtrace:

> (gdb) backtrace 
> No stack.
Comment 12 Bastien Nocera 2008-02-04 22:37:41 UTC
(In reply to comment #9)
> Firefox hangs when doing gdb attach...

Yes, you need to type "continue" into gdb to keep on running the program.

(In reply to comment #10)
> No core dump is saved or I can't find it.

It will be created in the current directory. If it isn't, try using:
sysctl -w "kernel.core_pattern=/tmp/core"
it will dump the core files in /tmp

Core dumps aren't created if you run the program within gdb.

> PS: Not 'unlimit' but 'ulimit'.

Yeah, typo.

(In reply to comment #11)
> gdb output: http://wklej.org/id/b951f39b78
> 
> still not backtrace:

/home/livio/Pobrane/firefox/firefox-bin: symbol lookup error: /usr/lib/mozilla/plugins/libtotem-gmp-plugin.so: undefined symbol: _ZN8nsMemory5CloneEPKvj

The totem there needs rebuilding, but:
1) Firefox shouldn't crash when there's an undefined symbol in a plugin
2) Firefox should stop breaking the ABI

I think the bug you're looking at is (it's a tracker bug):
https://bugzilla.mozilla.org/show_bug.cgi?id=156493
Comment 13 Jakub 'Livio' Rusinek 2008-02-04 23:02:04 UTC
> totem there needs rebuilding
Current or newer version should I build/use?

> 1) Firefox shouldn't crash when there's an undefined symbol in a plugin
> 2) Firefox should stop breaking the ABI
> 
> I think the bug you're looking at is (it's a tracker bug):
> https://bugzilla.mozilla.org/show_bug.cgi?id=156493

I don't know. I just wanted to tell both environments that some bug exists and someone needs to fix it, whomever it belongs to.
Comment 14 Jakub 'Livio' Rusinek 2008-03-12 15:49:22 UTC
I've tested Epiphany/XULRUnner 2.21.92. Crashes.
Comment 15 Jakub 'Livio' Rusinek 2008-03-12 15:50:35 UTC
Reassigning.
Comment 16 Bastien Nocera 2008-03-12 16:07:39 UTC
Did you get the plugin rebuilt so it doesn't have undefined symbols anymore?
Comment 17 Christian Persch 2008-03-12 16:10:28 UTC
Do not reassign bugs. This definitely belongs in totem; it needs to stop using nsMemory:: and just use the exported NS_* calls. Ultimately will be fixed by bug 520629.
Comment 18 Jakub 'Livio' Rusinek 2008-07-30 13:56:55 UTC
strange, but this bug doesn't appear in openSUSE. both 10.3 and 11.0.

not sure how about Fedora 9, since I use only openSUSE right now and even don't think about changing it ;) .
Comment 19 Bastien Nocera 2008-07-30 14:04:15 UTC
Closing then.