[siglist] Add -[NSApplication _crashOnException:] to the prefix list
Categories
(Socorro :: Signature, task, P2)
Tracking
(Not tracked)
People
(Reporter: gsvelto, Assigned: willkg)
Details
Attachments
(1 file)
Thanks to bug 1371390 we're getting much better crashes on macOS now... but we need to tell them apart. There's at least two stacks hiding behind this signature:
-[NSApplication _crashOnException:]
This is one which looks like it's related to CoreAnimation: https://crash-stats.mozilla.com/report/index/b3ddba51-86df-4a80-918e-e9b3b0191125
0 AppKit -[NSApplication _crashOnException:]
1 AppKit __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke
2 CoreFoundation ___CFXPCCreateCFObjectFromXPCObject_block_invoke
3 CoreFoundation CFRunLoopRemoveObserver
4 CoreFoundation __CFRunLoopRun
5 CoreFoundation __CFTSRToDispatchTime
6 HIToolbox RunCurrentEventLoopInMode
7 HIToolbox ReceiveNextEventCommon
8 HIToolbox _BlockUntilNextEventMatchingListInModeWithFilter
9 AppKit _DPSNextEvent
10 AppKit -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
And this is another, having to do with displaying strings (maybe?): https://crash-stats.mozilla.com/report/index/4a850fbe-360b-465d-bba6-57c3d0191121
0 AppKit -[NSApplication _crashOnException:]
1 AppKit __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.31
2 CoreFoundation CFStringFold
3 CoreFoundation CFStringFold
4 CoreFoundation CFCharacterSetIsCharacterMember
5 CoreFoundation CFStringCapitalize
6 HIToolbox RunCurrentEventLoopInMode
7 HIToolbox ReceiveNextEventCommon
8 HIToolbox _BlockUntilNextEventMatchingListInModeWithFilter
9 AppKit _DPSNextEvent
10 AppKit -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
|
Assignee | |
Comment 1•5 years ago
|
||
Working on this now.
|
|
Assignee | |
Comment 2•5 years ago
|
||
I'm assuming we want to build a signature that ends in a XUL frame. For both of these crash reports, we're going to have to add a bunch of the intermediary frames and the names are so long that I think the signature will get truncated.
Is it the goal to build a signature for these crash reports that ends in a XUL frame? Or is it sufficient to build a signature of just the first few frames?
|
||
Comment 3•5 years ago
|
||
To my mind, all you need to do is go back to a stack frame whose "signature" isn't already in your prefix list. So in gsvelto's example from comment 0, you'd go back to __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke or __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.31. Each of these is quite distinctive, and sufficient to give you a general idea of what's going wrong (a CA "transaction" in the first case, and something to do with displays in the second).
There are other signatures that are very generic (like __cxa_rethrow), but which aren't yet in the prefix list. I'll dig around and open a bug on each of them, using this bug as a template.
|
Reporter | |
Comment 4•5 years ago
|
||
What Steven said; this is a loop we call from Gecko but which runs in Apple code so the Gecko code isn't interesting but the second frame is because it tells you what's going on. Note that we also have bug 1579688 to see if we can make these signatures better by extracting the root crash reason from the exception handler. :KrisWright had a look but IIRC she couldn't find an easy solution.
|
|
Assignee | |
Comment 5•5 years ago
|
||
Cool. I'll add the following three items to the prefix list:
-[NSApplication _crashOnException:]__65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke__37+[NSDisplayCycle currentDisplayCycle]_block_invoke.31
Thanks!
|
|
||
Comment 6•5 years ago
|
||
Oops, I meant for you only to add -[NSApplication _crashOnException:] to the prefix list.
But maybe I've misunderstood what the prefix list is. I've assumed that it's a list of "signatures" that aren't distinctive to stand on their own. They need to be used in combination with others that are more distinctive.
So, in gsvelto's example, we'd end up with crash stacks with either of the following signatures:
-[NSApplication _crashOnException:] | __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke
-[NSApplication _crashOnException:] | __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.31
|
|
Assignee | |
Comment 7•5 years ago
|
||
|
|
Assignee | |
Comment 8•5 years ago
|
||
Ahh... ok. The summary says "NSApplication ... and other functions" and apparently I didn't understand the followup comments.
The signature generation documentation is here:
https://socorro.readthedocs.io/en/latest/signaturegeneration.html
That covers how it works, what the files do, and how to test signature generation changes.
I'll fix the PR now. Thanks!
|
|
Reporter | |
Comment 9•5 years ago
|
||
(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #8)
Ahh... ok. The summary says "NSApplication ... and other functions" and apparently I didn't understand the followup comments.
Sorry, my mistake, I must have copy-pasted the title from a similar bug blushes
|
|
Reporter | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 10•5 years ago
|
||
willkg merged PR #5041: "bug 1599019: add NSApplication functions to prefix list" in 2437f12.
I'll push this to prod on Monday, December 2nd. We can reprocess crash reports then if that helps.
|
|
||
Comment 11•5 years ago
|
||
I'll dig around and open a bug on each of them, using this bug as a template.
I just added fourteen of them :-) I found them by looking through the lists of Mac topcrashers.
|
|
Assignee | |
Comment 12•4 years ago
|
||
I just pushed this to prod in bug #1600745.
Description
•