no access to "about:crashes"

Bug #246843 reported by Pritch
28
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Mozilla PPA Bugs
New
Undecided
Unassigned
firefox-3.0 (Ubuntu)
Invalid
Wishlist
Unassigned
Nominated for Hardy by Connor Imes
Nominated for Intrepid by Connor Imes

Bug Description

Binary package hint: firefox-3.0

After suffering from several crashes regarding "closing tabs" (already subscribed to a bug report about this") I thought I might see how firefox reports the crash internally. Although I can see other options under the "about:" page there is no "about:crashes" option. When I type in the address all I get is an alert dialog box with the message "The URL is not valid and cannot be loaded.".

Revision history for this message
Connor Imes (ckimes) wrote :

I can confirm this bug in Hardy and Intrepid, so I will mark this as Triaged and put it on Wishlist.

Looking at the diff page - http://archive.ubuntu.com/ubuntu/pool/main/f/firefox-3.0/firefox-3.0_3.0~b5+nobinonly-0ubuntu3.diff.gz - we see, "Disable crash reporter" for "firefox-3.0 (3.0~b1+nobinonly-0ubuntu1) hardy; urgency=low" which is the FF3 beta 1 release as modified for Ubuntu.

It would seem appropriate that firefox should explain to you why it cannot access the about:crashes page. It is understandable that this functionality would have been disabled if Mozilla doesn't want crash reports from Ubuntu's modified version, but instead wants those bugs posted here on LP manually or through apport.

Therefore, we would request that Ubuntu's firefox explains to the user why crash reporter has been disabled and tells the user what they should do to report bugs/crashes when the user tries to access about:crashes.

Thank you.

Changed in firefox-3.0:
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

Currently all Linux distributions disable our crash reporting. It's widely held that there are a lot more users running their distribution's version of Firefox than there are running the official Linux Firefox builds. I've heard interest expressed from asac (from Ubuntu) and Wolfgang (from openSUSE) in submitting crash reports to our Socorro instance. I think this would be a win-win situation, as we're not currently getting visibility into the crashes our Linux users are actually hitting, and the distros (afaik) don't have the kind of aggregate reporting we do.

This is filed as a tracking bug, because there are going to be a few things necessary on both sides to make this happen, and each distro that wants to participate will have to do a few of the same things.

Brief list of what we'll need:
1) Need a "distributor" field in the Socorro database, so we can distinguish official mozilla.org builds from distro-produced builds (and distinguish distro builds from each other) Probably also want a distro_version, for their use. (bug 437487)
2) Distros will need access to upload symbols for their builds and the system libraries they depend on to our symbol store. This shouldn't be that hard, but I don't know what the space requirements are going to look like, we'll need to coordinate with IT on that. Additionally, distros will have to sort out automated upload of symbols for their packages, since our Breakpad setup doesn't have on-demand symbol supplying.
3) Clearly we'll need to sort out the load situation on our Socorro processor, since we are currently extremely backlogged, and throwing more reports at it isn't a great idea until we have some server-side throttling in place.

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote :

Or how about not disabling it since it does not appear that Ubuntu [can] do much about firefox crashes except suggesting to disable this or uninstall that.. or maybe it's the other.

If the actual crash report data would be useful to mozilla.org, then I'm all for sending it there since the stack traces I've sent to LP seem to get glossed over in favor of a more "stab-in-the-dark" approach to solving FF3 crashes.

Revision history for this message
John Vivirito (gnomefreak) wrote :

We package it without that option because we prefer you to file bugs in Launchpad first because not all firefox crashes are related to upstream package. That option is mainly for Mac and Windows because they dont have a central bug tracker.

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Connor Imes (ckimes) wrote :

Thanks for the update John. Shouldn't this be closed as Won't Fix?

Revision history for this message
Andrew (andrewkvalheim) wrote :

> Therefore, we would request that Ubuntu's firefox
> explains to the user why crash reporter has been
> disabled and tells the user what they should do
> to report bugs/crashes when the user tries to
> access about:crashes.

Is this covered in this bug report? Should the bug be reopened to request this?

Revision history for this message
Snap (snap-56k) wrote :

No data about crashes are collected right now, would it be possible/wanted to collect and send these data to a Ubuntu/Launchpad/Canonical/whatever Breakpad server? Then if the crash is not related to Ubuntu, the data could be transmitted to Mozilla Breakpad server.

Revision history for this message
In , Alexander Sack (asac) wrote :

(In reply to comment #0)
> Currently all Linux distributions disable our crash reporting. It's widely held
> that there are a lot more users running their distribution's version of Firefox
> than there are running the official Linux Firefox builds. I've heard interest
> expressed from asac (from Ubuntu) and Wolfgang (from openSUSE) in submitting
> crash reports to our Socorro instance. I think this would be a win-win
> situation, as we're not currently getting visibility into the crashes our Linux
> users are actually hitting, and the distros (afaik) don't have the kind of
> aggregate reporting we do.
>
> This is filed as a tracking bug, because there are going to be a few things
> necessary on both sides to make this happen, and each distro that wants to
> participate will have to do a few of the same things.

> 2) Distros will need access to upload symbols for their builds and the system
> libraries they depend on to our symbol store. This shouldn't be that hard, but
> I don't know what the space requirements are going to look like, we'll need to
> coordinate with IT on that. Additionally, distros will have to sort out
> automated upload of symbols for their packages, since our Breakpad setup
> doesn't have on-demand symbol supplying.

Is there any way we need to flag those symbols so you can match the right versions? I guess they should be somehow associated with a build/distro/distro-version id? For instance, our symbols for hardy might be different than those for jaunty. Same for 3.5.2 vs. 3.5.0.

Let's understand that first and I will see how we can upload them automatically.

> 3) Clearly we'll need to sort out the load situation on our Socorro processor,
> since we are currently extremely backlogged, and throwing more reports at it
> isn't a great idea until we have some server-side throttling in place.

You think that ubuntu/distro user base is high enough to make a big difference?

Revision history for this message
In , Benjamin Smedberg (Mozilla) [:bs] (benjamin-smedbergs) wrote :

> Is there any way we need to flag those symbols so you can match the right
> versions? I guess they should be somehow associated with a
> build/distro/distro-version id? For instance, our symbols for hardy might be
> different than those for jaunty. Same for 3.5.2 vs. 3.5.0.

In terms of finding the right symbols, no. The crash report contains a shared library signature which should be different.

But we'd probably want to have a manifest file of which symbol files belong to which releases, just for maintenance and eventual cleanujp.

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

As bsmedberg said, symbols on Linux are identified by an md5sum of some bits of the ELF file, so there's no need for any sort of mapping. The symbolstore.py script that we use to generate our symbols for nightly/release builds does produce a manifest file that we use for cleanup:
http://symbols.mozilla.org/firefox/firefox-3.5-WINNT-20090624025744-symbols.txt
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/tools/symbolstore.py

(In reply to comment #1)
> You think that ubuntu/distro user base is high enough to make a big difference?

Not now, but when I wrote that we were having serious issues keeping up with our existing load, so any additional user base might have been a problem. I think we've got that fairly well under control, and once my patch to resubmit reports (bug 378528) lands, we'll be able to throttle client-side and be in even better shape.

In short, I think we're in a good place to make this happen now. Let's figure out how to do it!

Revision history for this message
In , Mike Connor (mconnor) wrote :

Something like "the distributor of this application has disabled the crash reporter in this release" as text.

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

For reference, currently we don't enable the about:crashes URL at all unless crash reporting is enabled:
http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsAboutRedirector.cpp#73

And the content gets built in toolkit/crashreporter, which doesn't get built unless crash reporting is enabled:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/jar.mn

Revision history for this message
cardonator (bcardon) wrote :

Like #6, my problem is that I'm segfaulting with no way to figure out what kind of information about:crashes would even contain. This is on Jaunty Ubuntu 3.5.3 from the repos.

I tried running firefox with

strace -f -eopen firefox &> /tmp/ffox.log.txt

Is that the same info that about:crashes would contain?

Revision history for this message
Ted Mielczarek (ted-mielczarek) wrote :

I've talked with asac about getting Ubuntu Firefox builds to a point where they can submit to Mozilla's crash reporting server. We have a bug filed on this:
https://bugzilla.mozilla.org/show_bug.cgi?id=447771

It mostly just involves getting debug symbols uploaded from each build to our server.

We also had a bug filed recently on making about:crashes more informative when crash reporting is disabled, which would at least let you know what was happening:
https://bugzilla.mozilla.org/show_bug.cgi?id=511713

Sir_Brizz: you should be able to install the -dbg packages, and just use gdb to get a stack trace.

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote : Re: [Bug 246843] Re: no access to "about:crashes"

On Mon, 2009-09-14 at 16:02 +0000, Ted Mielczarek wrote:
>
> Sir_Brizz: you should be able to install the -dbg packages, and just use
> gdb to get a stack trace.

Yeah, well, that is all fine and dandy, but what Mozilla wants is what
comes out of it's crash tool. Yet I can't get them this info because
Canonical have decided that they don't want users to be able to send
that info (how nice of them, huh?).

Instead we can file bug reports complete with stack traces with
Canonical only for them to ignore the stack traces and start playing the
"try this" and "try that" and "can you try the next version" and "does
it work if you stand on only the big toe of your right foot and touch
your left ear with your right thumb" games. No actual debugging or
anything, just needle in a haystack searches.

If I could send Mozilla the info they want, they would at least actually
try to look at the info and debug it. This is as I do with evolution.
I have *completely* given up on sending evolution bug reports to
Canonical and file them directly with Gnome now. At least I don't get
the silly "try this" and "try that" games from them.

The summary is, don't disable tools which enable your users to help
themselves with buggy software when they know they are going to get
(next to) no help from bugs filed with Canonical.

Revision history for this message
Ted Mielczarek (ted-mielczarek) wrote :

No, what Mozilla wants is a stack trace. We ask for a crash report because that's the easiest way to get it for most of our users. If you can install -dbg packages and get a stack trace with gdb, that's useful as well.

Ubuntu has disabled the crash reporter because without also uploading debug symbols to Mozilla's symbol server, the crash reports are useless. We'd love to get that fixed, it just takes some work.

Revision history for this message
In , Jhorak (jhorak) wrote :

Fedora has recently developed its own system-wide automatic bug reporting tool - Abrt (https://fedorahosted.org/abrt/wiki). It can be used to automatically post crash reports to http://crash-stats.mozilla.com by writing a plugin. To create bug reports it use/download debug info packages for correspondent package for Fedora to user computer. If it is preferred approach for Fedora distribution I can try to do the plugin for http://crash-stats.mozilla.com. The benefit for Fedora users it allows to do bug reports from any application by similar way.

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

Our crash reporting system works the opposite way, sort of. We simply generate a minidump on the client side that includes the raw stack data and registers, and upload it to our crash report server, which has debug symbols that are uploaded from when we build the binaries.

All we really need to get useful crash reports from your users is:
1) You run the "make buildsymbols" in the Firefox (or xulrunner) objdir before packaging the build, and upload the symbols to our symbol server (we have "make uploadsymbols" for that, as well)
2) You start building without --disable-crashreporter, which will let your builds use our existing crash reporting mechanism to submit to our crash reporting server.

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

And, to answer your more direct question, no, our crash reporting server is not setup to accept stack traces produced in the manner you describe. It only accepts binary minidumps currently.

Revision history for this message
In , Jhorak (jhorak) wrote :

I see. I'm trying to bring up this issue in Fedora Devel list if it is possible or how can we work on it. Thanks for comments.

https://www.redhat.com/archives/fedora-devel-list/2009-September/msg00712.html

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

Feel free to CC me on any discussions.

Revision history for this message
In , Jhorak (jhorak) wrote :

I tried to do the 'make buildsymbols' with --enable-crashreporter. I'm unable to generate debug info unless I add -gstabs+ or -gstabs to CFLAGS. Where should I add this gcc parameters and which one should I choose (for Firefox and Thunderbird)?

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

Right, you'll need to build with debug symbols, which requires stabs symbols currently (we have DWARF support coming soon). If you're building with a mozconfig, you can pass that in CFLAGS/CXXFLAGS in your mozconfig, otherwise if you're just running configure manually, you can do:
CFLAGS=-gstabs+ CXXFLAGS=-gstabs+ ../configure ...

Revision history for this message
In , Jhorak (jhorak) wrote :

We can put thunderbird-*crashreporter-symbols.zip into our debuginfo package (for example thunderbird-debuginfo-3.0-3.10.b4.fc12.x86_64.rpm) which is located at http://kojipkgs.fedoraproject.org/packages/thunderbird/3.0/ (according to release and architecture). Are you able to pull these files and retrieve your symbols from this package (or would you like some assistance)?

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

It would be a lot easier if we just gave you an account and you uploaded the symbols to us instead.

Revision history for this message
In , Jhorak (jhorak) wrote :

Okay, but doing it manually is a bit unreliable. Looking at upload_symbols.sh, the script use ssh to upload files and it requires stored private key (so we can't make it public). I will have to discuss it with Fedora release engineering and then let you know.

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

Well, it just requires a private key be available on the box that does the uploading. You can see our production configs here:
http://mxr.mozilla.org/build/source/buildbot-configs/mozilla2/config.py#234

It just points to the private key which is installed on our build slaves.

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

Also, I didn't intend for it to be done manually, I was thinking you'd do this as an automated step as part of your build process, just like we do. Trying to set something up where we have to download your symbols and then install them after you've uploaded your build seems a lot more fragile.

Revision history for this message
In , Jruderman (jruderman) wrote :

Should we also encourage distros to put their own instructions for getting a stack trace into about:crashes? (See also bug 447771)

Revision history for this message
In , Jruderman (jruderman) wrote :

See also:
* Bug 511713, "When crash reporter is disabled, about:crashes should say that"
* https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/246843

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

"yes"

Revision history for this message
In , Matěj Cepl (mcepl) wrote :

(In reply to comment #15)
> Also, I didn't intend for it to be done manually, I was thinking you'd do this
> as an automated step as part of your build process, just like we do. Trying to
> set something up where we have to download your symbols and then install them
> after you've uploaded your build seems a lot more fragile.

We would have to do some changes in our building process (or maybe somewhere later) ... building process is not allowed to access network (for reasons which shouldn't be that difficult to understand, I hope). That's not insurmountable obstacle, just to note what needs to be done.

Revision history for this message
In , Ted Mielczarek (ted-mielczarek) wrote :

Ok. So, presumably, they have access to some server to which they upload the build results, right? If you can simply call "make buildsymbols" in the object directory, you'll wind up with a file in dist/ with a similar name to the build package, but ending in .crashreporter-symbols.zip. (You can see some of them in the upload directories here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux/ )

If you upload that symbol package along with the build, you could have a post-build process run elsewhere that uploads the contents of that zip to our symbol server. Our symbol upload script is quite simple:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/tools/upload_symbols.sh

We just run that script, passing the crashreporter-symbols.zip as the only argument, with some environment variables (described in the script) indicating the symbol server hostname and user login etc. You could use that or roll your own, it doesn't really matter.

Revision history for this message
Yann Dìnendal (yannbreliere) wrote :

I can't access about:crashes anymore on firefox-trunk.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

That's because the crash reporter is switched off at the moment

Revision history for this message
Alex Mayorga (alex-mayorga) wrote :

Mr. Coulson,

Could you please flip that switch to on?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.