Closed Bug 1583247 Opened 10 months ago Closed 1 month ago

Tab crashes don't allow Ubuntu users to submit tab crash reports

Categories

(Core :: DOM: Content Processes, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox79 --- fixed

People

(Reporter: mconley, Assigned: gsvelto)

References

()

Details

(Whiteboard: [sci-exclude])

Attachments

(1 file)

STR:

  1. Run a Canonical-built Firefox, installed via apt.
  2. Open a tab
  3. Visit about:crashcontent

ER:

A tab crash should occur such that the user can submit a crash report.

AR:

A tab crash occurs, but the user is not given the ability to submit a tab crash report to Mozilla.

Originally, I thought this was because Canonical didn't send Mozilla symbols for their builds, so we intentionally didn't collect crash reports for their builds, but then Gene showed me that by going to about:parentcrash, the crashreporter client spawns and a crash report with symbols is created.

Interestingly, I cannot reproduce this using a self-built Nightly on Ubuntu 18.04.1LTS, a Mozilla-built Nightly for today, nor the built in release version of Firefox that is currently installed by default in Ubuntu from Canonical.

I've started scraping symbols for Firefox packaged builds just last week. Before all those crashes were not being symbolicated properly. I don't know why crash reporting doesn't work just for tab crashes, it seems odd... I'll have to reproduce myself to figure it out.

On a side note we're scraping symbols also for Debian and Arch packaged Firefox builds. Not Fedora/RedHat/CentOS yet though because our tools can't process their debug information correctly.

I've installed the latest Ubuntu (19.04) in a VM and crashed a content process, crash submission seems to be working fine:

https://crash-stats.mozilla.com/report/index/97f4a9c0-a4bd-4d25-ae05-35c4c0190924

As you can see the stack trace is fully symbolicated as we now have symbols for all their builds.

This is another crash that I triggered by killing the content process with kill -ABRT:

https://crash-stats.mozilla.com/report/index/af52da0a-42b1-4070-b1c5-36e7e0190924

One odd thing is that the "tab crashed" prompt doesn't seem to submit the crash right away when I restart the tab. I had to go to about:crashes and submit it from there. This is worth investigating.

I have confirmed that sending a content crash report from the "tab crashed" page doesn't work with Ubuntu's packaged build. Submitting the same crash from about:crashes works though. I've tried one of our builds on Ubuntu to double-check and sending crashes from the "tab crashed" page also works correctly. I'll open a bug on Canonical's tracker. In the meantime users can use the "about:crashes" page to submit their crashes or enable auto-submission which should work.

Alright, I filed a bug in the Ubuntu bug tracker.

One odd thing is that the "tab crashed" prompt doesn't seem to submit the crash right away when I restart the tab. I had to go to about:crashes and submit it from there. This is worth investigating.

Maybe this is what I'm encountering (in my Firefox 69.0 on Ubuntu 18.04.3 LTS). Here's my sequence.

  1. Go to the tab that I can make crash
  2. Click the link in that tab that takes me to the page that crashes the tab
  3. The tab crash error message appears in the tab
  4. No popup appears to report the crash (like I've seen happen when the entire Firefox crashes)
  5. I go to about:crashes and nothing is shown related to the tab crash that just happened

Is there a step I should be doing in between when the tab crashes and when I go to about:crashes? When you say restart the tab, do you mean just browse to some other URL in the same tab that has the crashed tab error message?

(In reply to Gene Wood [:gene] from comment #8)

Is there a step I should be doing in between when the tab crashes and when I go to about:crashes? When you say restart the tab, do you mean just browse to some other URL in the same tab that has the crashed tab error message?

You need to push either the "Close Tab" or "Restore This Tab" buttons in that page. That being said, do you see an unsubmitted crashes in "about:crashes" or no crashes at all? If it's the latter then the problem is bigger than I thought.

I haven't tested Ubuntu LTS yet but I'll give it a spin and see what gives.

You need to push either the "Close Tab" or "Restore This Tab" buttons in that page.

Aha, I was doing neither of these.

That being said, do you see an unsubmitted crashes in "about:crashes" or no crashes at all? If it's the latter then the problem is bigger than I thought.

No, no tab crashes show up in my about:crashes. When I first posed the question to :mconley I just had 2 firefox crashes from 2018 in there. Mike had me trigger a full firefox crash and that showed the popup and added a new crash to about:crashes. However the tab crash that I've reproduced about 4 or 5 times has never showed up in about:crashes. To be fair though I've never clicked either close or reload links in the tab crash error page.

Is there a way to force / simulate a tab crash as I'm having trouble finding the audio file that I was playing yesterday that was causing the crash? I'd like to click the close or restore buttons to see if it causes the tab crash to show up in about:crashes

(In reply to Gene Wood [:gene] from comment #10)

Is there a way to force / simulate a tab crash

Yep, visit about:crashcontent.

Thank you. So yesterday, when getting the tab crash, my tab crash page showed this

https://i.imgur.com/e5sXdMw.png

and if I go to about:crashcontent I see this different crash page with a way to submit a report

https://i.imgur.com/TJ9DAAC.png

(In reply to Gene Wood [:gene] from comment #12)

Thank you. So yesterday, when getting the tab crash, my tab crash page showed this

https://i.imgur.com/e5sXdMw.png

It would be very useful if you could reproduce this particular issue. This one is bad and it shouldn't happen because it means that no crash reporter was generated at all even though the tab crashed.

It would be very useful if you could reproduce this particular issue. This one is bad and it shouldn't happen because it means that no crash reporter was generated at all even though the tab crashed.

I was able to reproduce it again this morning. I just need to know what to do when it happens to get you or someone useful information on what's happening. If you've got steps that you would do when this happens I'm happy to run them.

Chatted with :gsvelto a bit, he's going to look into how to launch gdb and bind to child processes in order to capture some information about what's going on.

Flags: needinfo?(gsvelto)

Since the crash is happening in a content process and we attaching gdb to all of them would be very tricky we'll cheat. Here's what you can do to get a backtrace:

  • First of all install firefox' debuginfo package so that you have symbols
    sudo apt-get install firefox-dbg
  • Then launch firefox, go into about:config and change the dom.ipc.processCount to 1. This will limit Firefox to a single content process which will make debugging much easier. Once this is done close Firefox.
  • Then re-launch firefox from the terminal with the crash reporter explicitly disabled:
    env MOZ_CRASHREPORTER_DISABLE=1 firefox
  • From another terminal attach gdb to the sole content process, this command should do the trick:
    gdb attach $(ps -eo pid,comm | grep Web\ Content | cut -b1-6)
    Note that this operation might take several seconds as gdb reads Firefox' huge debug information
  • Once gdb is attached the content process will be frozen, type c and return in the gdb prompt to resume execution.
  • Use Firefox and wait for the crash to happen.
  • When it crashes all your pages will be frozen since there's only one content process for them all. Go into the terminal where you launched gdb and get a backtrace with the bt command then print out the contents of the signal handler information with p $_siginfo. Attach everything here :-)
Flags: needinfo?(gsvelto)

With the help of the Ubuntu maintainer we tracked down the issue: apparently the Ubuntu packaging was not shipping the minidump-analyzer.exe tool and this was causing the odd behavior. So there's two issues here: first the lack of minidump-analyzer.exe which they are addressing, and secondly the fact that when it's missing the tab crashed page doesn't show up correctly. The latter is an issue on our side and I'll fix it in this bug.

Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [sci-exclude]
Pushed by gsvelto@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d1a0c02b53db
Handle errors in minidump analysis so that crashes can always be submitted r=mconley
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
QA Whiteboard: [qa-79b-p2]
You need to log in before you can comment on or make changes to this bug.