Closed Bug 1138399 Opened 5 years ago Closed 3 years ago

about:crashes doesn't list reports even if files exist under pending directory

Categories

(Toolkit :: Crash Reporting, defect, critical)

36 Branch
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1319071
Tracking Status
firefox50 --- affected

People

(Reporter: whimboo, Unassigned)

References

Details

(Whiteboard: [fce-active-legacy])

Attachments

(1 file)

I have seen this lately when trying to check our Ubuntu machines for crashes, which happened quite a bit in the last days while running our Mozmill tests. By actually opening about:crashes in the browser none of those crashes were listed. It was an empty list, with no single entry shown. Checking the pending folder on disc revealed a lot of unsent crash reports.

I talked to Ted on IRC and he mentioned to me that he was seeing something similar on his local Ubuntu machine.
This is becoming a huge problem nowadays. None of the crashes we have on our Mozmill CI machines can be sent because they are not listed at all. Also when I copy the files to my local pending folder I can see the same behavior. No single pending crash is listed.
Ted, do you have an idea? Is there a workaround to manually trigger a crash report submission?
Severity: major → critical
Flags: needinfo?(ted)
No, sorry, there's no way to manually submit crashes outside of about:crashes right now. I don't know what's going on here short of investigating to find the bug.
Flags: needinfo?(ted)
CC'ing Robert because I think this bug is important for him.
(In reply to Henrik Skupin (:whimboo) from comment #2)
> Is there a workaround to manually trigger a crash report submission?

Open the browser console (ctrl+shift+J) and paste the following line in, with `ID` replaced with the crash ID in the pending dir. (filename prior to extension; no "bp-"; include the quotes):

Components.utils.import("resource://gre/modules/CrashSubmit.jsm").CrashSubmit.submit("ID",{recordSubmission:true,noThrottle:true});

After doing so, you can refresh about:crashes and it will be in the list.

The about:crashes page really should just prompt to attempt to resend any pending reports if it opens and finds any.
(In reply to Dave Garrett from comment #5)
> Open the browser console (ctrl+shift+J) and paste the following line in,
> with `ID` replaced with the crash ID in the pending dir. (filename prior to
> extension; no "bp-"; include the quotes):
> 
> Components.utils.import("resource://gre/modules/CrashSubmit.jsm").
> CrashSubmit.submit("ID",{recordSubmission:true,noThrottle:true});

I will try that the next time when I hit this problem. Thanks.

> The about:crashes page really should just prompt to attempt to resend any
> pending reports if it opens and finds any.

Wasn't this always the case? I can remember back that I sent a lot of crash reports that way for ages. Did something stop this behavior? Maybe e10s related?
For that matter, why doesn't Firefox just kick off an async check to send any pending reports at startup?
(In reply to Dave Garrett from comment #7)
> For that matter, why doesn't Firefox just kick off an async check to send
> any pending reports at startup?

Probably because we have that rule to not send without prompting. Crash reports contain extremely privacy-sensitive data. That said, I think we actually should rethink our process and UI of sending crash reports and go more in the direction of a model like we do in Firefox OS, where we, by default, only prompt for the first crash, and if the person doesn't opt out, automatically send for subsequent cases. That said, the big question in such a case is losing the prompt for user comments, as those are actually very helpful at times to track down causes and find out how severe it feels to users.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8)
> (In reply to Dave Garrett from comment #7)
> > For that matter, why doesn't Firefox just kick off an async check to send
> > any pending reports at startup?
> 
> Probably because we have that rule to not send without prompting.

The crash reporter already prompts to send. If that is declined, the pending files should be deleted immediately and not even available to send. (maybe need a separate dir for staging dumps prior to officially being pending?)
Had the same problem that some reports weren't listed.
But this happened just some times after I switched to E10s.
Guess that crashes in the plugin-container.exe (on Windows), when the container is used for E10s, weren't right handled by the exe at the beginning of using the app for it.
The problem is now gone for me in the last weeks.

Platform: All/All ?
Tracking: E10s ?
Status  : Resolved ?
(In reply to Dave Garrett from comment #7)
> For that matter, why doesn't Firefox just kick off an async check to send
> any pending reports at startup?

We could add this behavior for reports that failed to send, that seems totally reasonable. Right now we don't actually record whether a report failed to send anywhere, however.

(In reply to Dave Garrett from comment #9)
> The crash reporter already prompts to send. If that is declined, the pending
> files should be deleted immediately and not even available to send. (maybe
> need a separate dir for staging dumps prior to officially being pending?)

This is how it works currently! Unfortunately we also get dumps in pending from things like plugin crashes, where the user might not interact with the crash UI (they can just reload the page), and we don't do anything with those, and we shouldn't submit them without user action. That's fixable, though.
Think a option under "about:preferences#advanced"\"Data Choises"\"Enable Crash Reporter" and then maybe "Resend unsend Reports" would be nice.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #11)
> Unfortunately we also get dumps in pending
> from things like plugin crashes, where the user might not interact with the
> crash UI (they can just reload the page), and we don't do anything with
> those, and we shouldn't submit them without user action. That's fixable,
> though.

I definitely would like to see a solution for not sending reports when the user clicks the [x] close button of the crash reporter window or when just hitting reload on the plugin or content crash prompts.
(In reply to Tobias B. Besemer [:BesTo] from comment #12)
> Think a option under "about:preferences#advanced"\"Data Choises"\"Enable
> Crash Reporter" and then maybe "Resend unsend Reports" would be nice.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #13)
> (In reply to Ted Mielczarek [:ted.mielczarek] from comment #11)
> > Unfortunately we also get dumps in pending
> > from things like plugin crashes, where the user might not interact with the
> > crash UI (they can just reload the page), and we don't do anything with
> > those, and we shouldn't submit them without user action. That's fixable,
> > though.
> 
> I definitely would like to see a solution for not sending reports when the
> user clicks the [x] close button of the crash reporter window or when just
> hitting reload on the plugin or content crash prompts.

(In reply to Tobias B. Besemer [:BesTo] from comment #14)
> Created attachment 8634668 [details]
> 2015-07-16 13_49_11-Options - Firefox Developer Edition (Build
> 20150715004006).png

Suggestion:
- Rename "Enable Crash Reporter" to "I want send in crash reports";
- Add as a sub-option "Resend unsend Reports" (as described above).

Maybe not the best, final solution, but easy & fast as a workaround for at least the next weeks.
Resend can be done after each (re-) start of the browser ones.
1) We need to have UX revisit the whole flow and not do one-off there.
2) We need in-depth privacy reviews of anything that switches away from "always have the user acknowledge sending a crash report" as there are multiple pieces of privacy-relevant data in there.
3) We need to think of how to not lose user comments to crash reports during that, as they often significantly help us diagnose the issues.

All in all, there is no way we can do *any* easy & fast fix here.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #17)
> 1) We need to have UX revisit the whole flow and not do one-off there.
> 2) We need in-depth privacy reviews of anything that switches away from
> "always have the user acknowledge sending a crash report" as there are
> multiple pieces of privacy-relevant data in there.
> 3) We need to think of how to not lose user comments to crash reports during
> that, as they often significantly help us diagnose the issues.
> 
> All in all, there is no way we can do *any* easy & fast fix here.

Robert,
I'm just talking about the un-submitted crash reports from the plugin-container (and those where the send failed) where the user have also no options when he send them out via about:crashes. Guess they also don't include URLs ...
I also guess that getting FF (and the container) should be such a high priority task, that a complete re-do of the crash report work-flow would take to long and the devs will miss to much crashers.
When a re-do of the crash reporting work-flow is done and programmed, the workaround can be un-done.
If you missed my workaround idea in details, I would only send out un-send crash reports on startup of FF without private data like the user can do it with about:crashes and only for profiles where "Enable Crash Reporter" is selected (mainly beta & alpha tester?).
Greets, Tobias.
I don't want to add a pref for this. We should just keep track of reports that we tried and failed to send and attempt to re-submit them at some point using the in-browser crash submission pipeline.

I think that's totally off-topic for this bug though, which is just about pending crashes not showing up in about:crashes. Please file a new bug.
(In reply to Tobias B. Besemer [:BesTo] from comment #10)
> Had the same problem that some reports weren't listed.
> But this happened just some times after I switched to E10s.
> Guess that crashes in the plugin-container.exe (on Windows), when the
> container is used for E10s, weren't right handled by the exe at the
> beginning of using the app for it.
> The problem is now gone for me in the last weeks.
> 
> Platform: All/All ?
> Tracking: E10s ?
> Status  : Resolved ?

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #19)
> I don't want to add a pref for this. We should just keep track of reports
> that we tried and failed to send and attempt to re-submit them at some point
> using the in-browser crash submission pipeline.

But what's about container crashes? Think they will not be tried to send, or?


OK, know OT but just some short questions because interested/involved people are here and it should be much easier & faster then in the mailing list ...
Would it be possible that when I (the user) load a crash report on Socorro via about:crashes that then Socorro knows that I (the user) was the submitter and I (the user) can add a user comment to the report as submitter of the report?
Means: Include the TXT on the user system something like a unique identifier to the report that nobody else can know ???
Can/should we fill a bug for this against Socorro ???
Just as a note there is no way to "only send [...] crash reports [...] without private data" as the core of the crash reports is the minidump which contains highly sensitive private data.

That said, what we talked about here should be part of bug 1177121 in any case.
Pending report from 2016-08-08.
OS: Linux → All
QA Contact: Tobias.Besemer
Whiteboard: [fce-active]
Now that bug 1319071 has landed new crashes will be detected correctly by about:crashes. Old ones will not since they still use the old (buggy) naming convention used by Breakpad only on Linux.
I've verified this was fixed by bug 1319071, nightly now correctly detects the minidumps.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1319071
Whiteboard: [fce-active] → [fce-active-legacy]
You need to log in before you can comment on or make changes to this bug.