Bug 233931 - Firefox crashes don't automatically trigger bug-buddy
Firefox crashes don't automatically trigger bug-buddy
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gecko Maintainer
Depends On:
  Show dependency treegraph
Reported: 2007-03-25 19:14 EDT by Christopher Beland
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-11 10:15:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Christopher Beland 2007-03-25 19:14:54 EDT
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
Comment 1 Martin Stransky 2007-04-11 08:23:51 EDT
Please try to run it from gdb ($firefox -g and then the "run" command). If it
crashes please attach a backtrace here ("bt" command).
Comment 2 Matthias Clasen 2007-04-11 10:15:17 EDT
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
bugs anyway. 

I think it is best to close this as WONTFIX for FC-6, at least.
Comment 3 Christopher Beland 2007-04-11 10:46:33 EDT
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.
Comment 4 Christopher Aillon 2007-04-11 10:57:34 EDT
It would be, but this support is going to come as part of Firefox itself in a
future release. 
Comment 5 Christopher Beland 2007-04-11 20:45:10 EDT
Ah, cool.

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.
Comment 6 Martin Stransky 2007-04-12 04:51:33 EDT
Ehm, just run "$firefox -g" from terminal. It'll load gdb for you....
Comment 7 Christopher Beland 2007-04-14 14:24:34 EDT
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.
Comment 8 Christopher Beland 2007-04-14 14:41:33 EDT
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
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x02e870f8 in Flash_EnforceLocalSecurity ()
   from /usr/local/beland/flash-player-plugin-
#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 ?? ()
   from /usr/local/beland/flash-player-plugin-
#8  0xbfb1d8f8 in ?? ()
#9  0x02e8113c in ?? ()
   from /usr/local/beland/flash-player-plugin-
Previous frame identical to this frame (corrupt stack?)
Comment 9 Matěj Cepl 2007-04-16 11:20:11 EDT
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
Comment 10 Christopher Beland 2007-04-16 11:32:00 EDT
The page you referenced says that Safe Mode disables extensions but not plugins.
Comment 11 Matěj Cepl 2007-04-16 11:39:30 EDT
You are right. Sorry for this.

Note You need to log in before you can comment on or make changes to this bug.