Crash stack entries of the form @0x7fffNNNNNNNN, mostly on macOS
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
People
(Reporter: smichaud, Unassigned)
References
Details
These occur as signatures and also as crash stack entries below the signature. But only those that occur as signatures can be quantified:
It's possible some of these entries point to the stack, but I think it's unlikely that all of them do, or even most of them. There are simply too many of them, and sometimes they occur as single entries in crash stacks that appear otherwise normal. The module information seems to be missing. This would only be correct if they actually were addresses on the stack.
It's hard to tell where these come from, but I suspect Rust.
Reporter | ||
Comment 1•5 years ago
|
||
If these entries don't point to the stack (as I suspect of most of them), they're corruptions in the crash stacks where they occur. And they occur often enough to be a serious problem, at least on the Mac.
Reporter | ||
Comment 2•5 years ago
|
||
To see examples of crash stacks that contain @0x7fffNNNNNNNN entries mixed in with seemingly normal ones, look at all threads in the search results from comment 0. For example:
https://crash-stats.mozilla.com/report/index/48d2d67f-cfba-41ac-85cc-65ee60191101#allthreads
Reporter | ||
Comment 3•5 years ago
|
||
The fix for bug 1371390, which just landed, should make a big difference here on the Mac. I'm hoping that it will even out the numbers, so that these crash stacks no longer appear disproportionately on the Mac. I'll check in a week or two.
Reporter | ||
Comment 4•5 years ago
|
||
These have almost vanished since my patch for bug 1371390 landed:
The few that are left are still disproportionately on macOS, but that may have to do with the particular signature fragment (0x7fff) that I chose to search on.
Let's resolve this FIXED. It can be reopened if the numbers start creeping up again.
Description
•