Add UI to display minidumps for multiple processes

NEW
Unassigned

Status

--
enhancement
4 years ago
a year ago

People

(Reporter: mconley, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [lang=python+html])

(Reporter)

Description

4 years ago
With e10s, it's possible for us to intentionally kill the child (ContentParent::KillHard), and we want to gather minidumps from both the parent and child process.

We would like the web interface for crash-stats to let us view the stacks for both processes.

I'm pretty sure this is a dupe - bsmedberg said something like this was filed - but I couldn't find the bug, so filing this one. needinfo'ing bsmedberg for the bug # to dupe to.
(Reporter)

Updated

4 years ago
Flags: needinfo?(benjamin)

Comment 1

4 years ago
I can't find the bug. So either I never filed it, or it was a comment in some other bug that got lost.

In any case, here are some details about how to fix this:

https://github.com/mozilla/socorro/blob/master/webapp-django/crashstats/crashstats/views.py#L998 is the view for report/index
https://github.com/mozilla/socorro/blob/master/webapp-django/crashstats/crashstats/templates/crashstats/report_index.html is the template

https://crash-stats.mozilla.com/report/index/8dbd0b34-4c6d-49cb-84f9-736132141215 is an example of a plugin hang report with four dumps.

My recommendation for UI would be to take the "Crashing Thread" section of the "Details" tab and wrap that in a tabbed UI with one tab for each dump. So in this case, there would be four tabs: "plugin,browser,flash1,flash2". And then show the crashing-thread UI within each tab.
Component: General → Webapp
Flags: needinfo?(benjamin)

Updated

4 years ago
Whiteboard: [lang=python+html]
Schalk, would you be interested in doing this one?
I think I can help with figuring out where the data would come from etc. And if the two of us get stuck, we'll always have bsmedberg to get us unstuck.
(In reply to Peter Bengtsson [:peterbe] from comment #2)
> Schalk, would you be interested in doing this one?
> I think I can help with figuring out where the data would come from etc. And
> if the two of us get stuck, we'll always have bsmedberg to get us unstuck.

Definitely, let me know what the next steps are. Although the next steps will most likely only happen Q1 right?

Comment 4

4 years ago
My request on IRC was for somebody to sign up as a mentor. I might be able to find a webdev volunteer to take the bug.

Comment 5

4 years ago
Is there any chance we can get cooking on this asap? We have thousands of orphaned content crash signatures showing up in crashstats with no way of correlating them with browser stacks. The browser stack is what we need to diagnose accurately. (See bug 1116884 for some detail.)
Blocks: 1116884
Depends on: 1068349
Flags: needinfo?(schalk.neethling.bugs)
(In reply to Jim Mathies [:jimm] from comment #5)
> Is there any chance we can get cooking on this asap? We have thousands of
> orphaned content crash signatures showing up in crashstats with no way of
> correlating them with browser stacks. The browser stack is what we need to
> diagnose accurately. (See bug 1116884 for some detail.)

I believe a web-dev volunteer/contributor is going to work on this with Peter as mentor.
Flags: needinfo?(schalk.neethling.bugs)

Comment 7

4 years ago
Peter, do we have someone lined up to work on this currently?
Flags: needinfo?(peterbe)
Assignee: nobody → peterbe
(In reply to Jim Mathies [:jimm] from comment #7)
> Peter, do we have someone lined up to work on this currently?

me! :)
Flags: needinfo?(peterbe)
Status: NEW → ASSIGNED

Comment 9

4 years ago
This UI really shouldn't be blocking anyone's work, since the data is all available via the API. I hacked together a quick viewer:

http://benjamin.smedbergs.us/tests/socorroloader/multiple-minidumps.html you can paste in the ID of a multi-dump report and it will show all the dumps side-by-side, e.g. 9a08adeb-1a87-4ba4-a641-f78882150119 (two dumps) or 8b7d2833-435e-4448-a6a9-1e8102150117 (four dumps).

Comment 10

4 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> This UI really shouldn't be blocking anyone's work, since the data is all
> available via the API. I hacked together a quick viewer:

Ahh, awesome! Is there a wiki or mdn page on this api?? I searched this week for docs on a socorro json api or similar but didn't find anything! I had hoped to find temp fix for this as well.

> http://benjamin.smedbergs.us/tests/socorroloader/multiple-minidumps.html you
> can paste in the ID of a multi-dump report and it will show all the dumps
> side-by-side, e.g. 9a08adeb-1a87-4ba4-a641-f78882150119 (two dumps) or
> 8b7d2833-435e-4448-a6a9-1e8102150117 (four dumps).

thanks, will take this for a spin today.
(In reply to Jim Mathies [:jimm] from comment #10)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> > This UI really shouldn't be blocking anyone's work, since the data is all
> > available via the API. I hacked together a quick viewer:
> 
> Ahh, awesome! Is there a wiki or mdn page on this api?? I searched this week
> for docs on a socorro json api or similar but didn't find anything! I had
> hoped to find temp fix for this as well.

It is somewhat self-documented at: https://crash-stats.mozilla.com/api/

We could probably do with better descriptions of each of the endpoints, hopefully the names are somewhat self-explanatory.

We're definitely open to suggestions for improvements and available to provide help if you can't find what you need or hit anything unexpected, either in bugs or IRC (#breakpad).

Comment 12

4 years ago
(In reply to Robert Helmer [:rhelmer] from comment #11)
> (In reply to Jim Mathies [:jimm] from comment #10)
> > (In reply to Benjamin Smedberg  [:bsmedberg] from comment #9)
> > > This UI really shouldn't be blocking anyone's work, since the data is all
> > > available via the API. I hacked together a quick viewer:
> > 
> > Ahh, awesome! Is there a wiki or mdn page on this api?? I searched this week
> > for docs on a socorro json api or similar but didn't find anything! I had
> > hoped to find temp fix for this as well.
> 
> It is somewhat self-documented at: https://crash-stats.mozilla.com/api/
> 
> We could probably do with better descriptions of each of the endpoints,
> hopefully the names are somewhat self-explanatory.
> 
> We're definitely open to suggestions for improvements and available to
> provide help if you can't find what you need or hit anything unexpected,
> either in bugs or IRC (#breakpad).

Great thanks. I've had a chance to look at some of these parent stacks finally - the information available is pretty limited. Knowing this and with the api documentation in hand to do more digging on my own.. I think we can downgrade the priority on this bug.
Severity: normal → enhancement
Hardware: x86 → All
I think this would help a lot for engineers who are less-experienced at dealing with crash-stats, to understand what data are available.

For example, a lot of platform developers have spun their wheels for quite a while on ShutDownKill crashes (whose signatures were just fixed in bug 1269817) without understanding that the crash reports they were looking at were the parent process killing the child process.  If paired minidump UI had been visible, people wouldn't have wasted nearly as much time on these.  (That said, that's far from the only problem that led to that situation, but I think it would have substantially reduced the time wasted.)
Assignee: peterbe → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.