Red Hat Bugzilla – Bug 233931
Firefox crashes don't automatically trigger bug-buddy
Last modified: 2007-11-30 17:12:00 EST
I have been experiencing Firefox crashes several times per week. I wish to
report stack traces for these crashes. Normally when desktop applications crash,
they trigger bug-buddy, which automatically extracts the stack trace and allows
me to submit it to Bugzilla fairly easily.
When Firefox crashes, this does not happen. This would be the most convenient
way to provide feedback and hopefully help the developers improve the stability
of the application.
Firefox Extension: Tab Mix Plus 0.3.5.2
Please try to run it from gdb ($firefox -g and then the "run" command). If it
crashes please attach a backtrace here ("bt" command).
Christopher, this is because firefox is not a gnome application.
Gnome applications get the bug-buddy support for free. Also, bug-buddy at this
time only reports bugs to gnome bugzilla, which wouldn't be correct for firefox
I think it is best to close this as WONTFIX for FC-6, at least.
Wouldn't it be useful to receive crash traces from people who don't know how to
use gdb? I would think if there were such a feedback loop, Firefox wouldn't be
crashing every other day.
It would be, but this support is going to come as part of Firefox itself in a
In the meantime, I'll try the gdb method. For the benefit of anyone else trying
to do the same thing:
I tried to run "gdb" and then "/usr/bin/firefox -g" at the gdb prompt, as the
above instructions seem to suggest. This didn't work and gave the error
'Undefined command: "". Try "help".'
If I do "run /usr/bin/firefox" I get "Starting program: /usr/bin/firefox" and
then "No executable file specified."
It turns out /usr/bin/firefox is a shell script, not a binary, but it sets up
some environment variables before starting *another* shell script, which in turn
starts the binary.
So I started Firefox normally, and then ran "attach PID" at the gdb prompt,
where PID is the process ID of firefox-bin, obtained from "ps auxw". It loaded
a bunch of symbol tables. Then I had to run "continue" at the gdb process to
allow the Firefox process to run normally. Hopefully this will allow me to
capture a backtrace in the event of a crash.
Ehm, just run "$firefox -g" from terminal. It'll load gdb for you....
Running "$firefox -g" at the prompt produces the error:
firefox: Undefined variable.
However running "firefox -g" works. The attachment method described above seems
to have failed when I played a youtube video, so I'll try this method instead.
I successfully obtained a backtrace (below). Looks like it's a problem with the
Flash Plugin I have installed. It's a beta version, so I'll upgrade and report
any future crashes in a new bug to the appropriate party. Thanks for all your help!
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208449328 (LWP 24179)]
0x00000000 in ?? ()
Current language: auto; currently c
#0 0x00000000 in ?? ()
#1 0x02e870f8 in Flash_EnforceLocalSecurity ()
#2 0x0e8a2da4 in ?? ()
#3 0x0000000f in ?? ()
#4 0xbfb1d8e8 in ?? ()
#5 0x07664098 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#6 0xb0aac000 in ?? ()
#7 0x034a9124 in ?? ()
#8 0xbfb1d8f8 in ?? ()
#9 0x02e8113c in ?? ()
Previous frame identical to this frame (corrupt stack?)
Christopher, sorry, using $ on the beginning of the line as a sign of shell
prompt is confusing, but quite common. Yes, Martin, meant that you should just
run firefox with the parameter -g, which you did.
It could be useful to run firefox also in the safe mode (i.e., with all plugins
disabled). Take a look at http://kb.mozillazine.org/Safe_Mode -- basically it
boils down to adding yet another paramter to firefox. So try to run
firefox -g -safe-mode
and then try to reproduce backtrace again. If everything works, then you have
proven, that the problem is not in firefox itself, but in some plugin (like in
The page you referenced says that Safe Mode disables extensions but not plugins.
You are right. Sorry for this.