Bug 233931 - Firefox crashes don't automatically trigger bug-buddy
Summary: Firefox crashes don't automatically trigger bug-buddy
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-25 23:14 UTC by Christopher Beland
Modified: 2018-04-11 08:12 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-04-11 14:15:17 UTC


Attachments (Terms of Use)

Description Christopher Beland 2007-03-25 23:14:54 UTC
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.

Installed:
firefox-1.5.0.10-5.fc6
firefox-debuginfo-1.5.0.10-5.fc6
bug-buddy-2.16.0-4.fc6
Firefox Extension: Tab Mix Plus 0.3.5.2

Comment 1 Martin Stransky 2007-04-11 12:23:51 UTC
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 14:15:17 UTC
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 14:46:33 UTC
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 14:57:34 UTC
It would be, but this support is going to come as part of Firefox itself in a
future release. 
http://benjamin.smedbergs.us/blog/2007-03-29/using-breakpad-with-19a3/

Comment 5 Christopher Beland 2007-04-12 00:45:10 UTC
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 08:51:33 UTC
Ehm, just run "$firefox -g" from terminal. It'll load gdb for you....

Comment 7 Christopher Beland 2007-04-14 18:24:34 UTC
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 18:41:33 UTC
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-9.0.21.78/libflashplayer.so
#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-9.0.21.78/libflashplayer.so
#8  0xbfb1d8f8 in ?? ()
#9  0x02e8113c in ?? ()
   from /usr/local/beland/flash-player-plugin-9.0.21.78/libflashplayer.so
Previous frame identical to this frame (corrupt stack?)


Comment 9 Matěj Cepl 2007-04-16 15:20:11 UTC
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
flash).

Comment 10 Christopher Beland 2007-04-16 15:32:00 UTC
The page you referenced says that Safe Mode disables extensions but not plugins.

Comment 11 Matěj Cepl 2007-04-16 15:39:30 UTC
You are right. Sorry for this.


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