Closed
Bug 1376717
Opened 7 years ago
Closed 7 years ago
Crash in js::jit::JitcodeGlobalEntry::callStackAtAddr
Categories
(Core :: JavaScript Engine: JIT, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla57
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox55 | --- | unaffected |
firefox56 | --- | wontfix |
firefox57 | --- | fixed |
People
(Reporter: cbook, Assigned: djvj)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
1.48 KB,
patch
|
mstange
:
review+
|
Details | Diff | Splinter Review |
This bug was filed from the Socorro interface and is report bp-c5276e49-ff44-4870-9349-bc4ea0170628. ============================================================= filing out of crash-stats
Comment 1•7 years ago
|
||
I just hit this myself, in a fresh Nightly profile (with gecko profiler 0.17 installed), on latest Linux64 nightly. bp-9b51a61b-526b-4565-aa33-914a40170629 In case it matters: I had just done Ctrl Shift 2 to submit a profile, after profiling ~20 seconds of me running multiple iterations of a Speedometer v2 subtest. We immediately had a content-process crash after I did ctrl shift 2.
Comment 2•7 years ago
|
||
This crash is almost making the profiler unusable for me these days when I set the threshold to anything below 1ms. Kannan, any chance you can take this please?
Flags: needinfo?(kvijayan)
Comment 3•7 years ago
|
||
Example: https://crash-stats.mozilla.com/report/index/c741d24c-f011-4ee7-85c8-996d90170728
Comment 4•7 years ago
|
||
And the reason for the crash is obvious, we don't null check the return value of lookupInfallible inside JS::ForEachProfiledFrame(): entry is null here: https://searchfox.org/mozilla-central/rev/09c065976fd4f18d4ad764d7cb4bbc684bf56714/js/src/jit/JitcodeMap.cpp#1665
Assignee | ||
Comment 5•7 years ago
|
||
The issue is that lookupInfallible is supposed to be, well, infallible. We should never fail this lookup. However, given that we are, and given that this issue has persisted for a while and is a high priority to fix... a band-aid solution while we search for the underlying issue is probably best.
Flags: needinfo?(kvijayan)
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → kvijayan
Assignee | ||
Updated•7 years ago
|
Priority: -- → P1
Assignee | ||
Comment 6•7 years ago
|
||
This is a band-aid fix to suppress the crash issues while we track down the weird issues with stackwalking. We shouldn't let the reproducibility of the underlying issue affect the UX of crashes using the profiler. Given that the former problem is hard to estimate a fix on, we should reduce the user burden of this bug. Sample based profiling is an inherently statistical process - the occasionally odd sample will not fundamentally affect the profiles, but a crash renders profiling completely useless.
Attachment #8905961 -
Flags: review?(mstange)
Comment 7•7 years ago
|
||
Comment on attachment 8905961 [details] [diff] [review] suppress-bug-1376717.patch Review of attachment 8905961 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!
Attachment #8905961 -
Flags: review?(mstange) → review+
Assignee | ||
Comment 8•7 years ago
|
||
So the next hypothesis for these crashes are that the stack walk is somehow occasionally returning callsite addrs that do not point to jitcode that's mapped (either pointing to non-jitcode, or trampolines, etc.) This shouldn't be happening, but there may have been changes to the stack layout that were not coordinated with updates to the profiler's jitcode stack walker. This needs to be investigated, but has proved extremely difficult to reproduce. It's happening rarely enough that it's not going to affect the fidelity of the profiler reports. We shouldn't hard-crash on a soft-failure of the profiler jitcode map not having an entry for a stackaddr. I'll land this once I verify the try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=0b340b7ebffcbeb372c263a9e09b9bf06cda96fa&selectedJob=130101335
Pushed by kvijayan@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/76192a7c0257 Do not crash on failed profiler table lookups for jitcode during report generation. r=mstange
Comment 10•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/76192a7c0257
Status: NEW → RESOLVED
Closed: 7 years ago
status-firefox57:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Comment 11•7 years ago
|
||
I assume we don't need to worry about backporting this since it's profiler-only. Feel free to set the status to affected and nominate it for Beta approval if you feel otherwise, though.
status-firefox55:
--- → unaffected
status-firefox56:
--- → wontfix
status-firefox-esr52:
--- → unaffected
Comment 12•6 years ago
|
||
I suspect this crash is due to a mechanism in Ion bailout where we overwrite the return address to within an IC stub instead of baseline mainline code. This would cause the return-address-to-JitCode lookup to fail leading to this crash.
Blocks: 1408105
You need to log in
before you can comment on or make changes to this bug.
Description
•