Closed
Bug 909743
Opened 11 years ago
Closed 11 years ago
Assertion failure: js::CurrentThreadCanAccessRuntime(runtime_), at ../vm/Runtime.h:1779 and Crash on Heap with Range Analysis
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
RESOLVED
FIXED
mozilla27
Tracking | Status | |
---|---|---|
firefox25 | --- | disabled |
firefox26 | --- | disabled |
firefox27 | --- | fixed |
firefox-esr17 | --- | unaffected |
firefox-esr24 | --- | disabled |
b2g18 | --- | unaffected |
People
(Reporter: decoder, Assigned: shu)
Details
(4 keywords, Whiteboard: [qa-])
Attachments
(2 files, 1 obsolete file)
477 bytes,
text/plain
|
Details | |
2.34 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase asserts on mozilla-central revision e42dce3209da (threadsafe build, run with --fuzzing-safe --ion-check-range-analysis --ion-regalloc=backtracking):
assertArraySeqParResultsEq(range(0, 512), "map", function(e) { return e+'x'; });
function range(n, m) {
var result = [];
for (var i = n; i < m; i++)
result.push(i);
return result;
}
function assertParallelExecSucceeds(opFunction) {
for (var i = 0; i < 100; ++i) {
opFunction({mode:"compile"});
}
}
function assertArraySeqParResultsEq(arr, op, func) {
assertParallelExecSucceeds(
function (m) {
return arr[op + "Par"].apply(arr, [func, m]);
}
);
}
Reporter | ||
Comment 1•11 years ago
|
||
Not sure if this is really related to range analysis or just coincidence that the option is needed. What is very strange is that the assertion pops up multiple times before the program aborts then (to be precise, it appears 605 times before I see "Segmentation fault").
Keywords: crash
Comment 2•11 years ago
|
||
I already saw this assertion before, when I was tweaking the fake-scheduling. I don't think this is related to range analysis.
Comment 3•11 years ago
|
||
Marking sec-high because I think some other similar assertion was high. Adjust as desired.
Keywords: sec-high
Comment 4•11 years ago
|
||
needinfo?'ing a PJS guy as this seems to call mapPar :)
Flags: needinfo?(nmatsakis)
Reporter | ||
Comment 5•11 years ago
|
||
Comment 6•11 years ago
|
||
Niko, any news here? Can you reassign if needed? Thanks.
Comment 7•11 years ago
|
||
No real news. Thus far, I have not been able to reproduce. I did see a fix for a similar assertion go by at some point, so perhaps this has been fixed, I will try running with an older revision.
Flags: needinfo?(nmatsakis)
Reporter | ||
Comment 8•11 years ago
|
||
Attachment #801507 -
Attachment is obsolete: true
Assignee | ||
Comment 9•11 years ago
|
||
I can repro, but no idea what's going on yet. I think the js::CurrentThreadCanAccessRuntime(runtime_) assert is bogus, I see a crash in jitcode.
Assignee | ||
Updated•11 years ago
|
Assignee: general → shu
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•11 years ago
|
||
Oops, that's bzexport screwing up above. So after 4 hours of EXCRUCIATING PAIN I finally figured out it's because I was too clever with the parallel string concat stub with reusing a temp (due to x86 having so few registers), and was clobbering a live pointer to a ForkJoinSlice.
Updated•11 years ago
|
Component: JavaScript Engine → JavaScript Engine: JIT
Comment 12•11 years ago
|
||
Comment on attachment 815235 [details] [diff] [review]
Save live ForkJoinSlice register in the fast string concat stub. (r=?)
Review of attachment 815235 [details] [diff] [review]:
-----------------------------------------------------------------
Good catch. Can you add the testcase as well?
Attachment #815235 -
Flags: review?(jdemooij) → review+
Assignee | ||
Comment 13•11 years ago
|
||
Comment 14•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Comment 15•11 years ago
|
||
Shu: Before landing patches for security bugs please follow the process at https://wiki.mozilla.org/Security/Bug_Approval_Process
As a sec-high bug this needed sec-approval before landing. Possibly you know something about whether it does or doesn't affect older branches that is not evident in this bug, and if so it would help to add that information /to/ the bug so you don't keep tripping our "Oh Shit" alarm about whether we just potentially 0-day'd all our release users.
Carsten: Please set the matching "status-firefoxXX" tracking flag to "fixed" in addition to setting the target milestone when you land security bugs. Thanks.
status-firefox27:
--- → fixed
status-firefox-esr17:
--- → unaffected
status-firefox-esr24:
--- → ?
Flags: needinfo?(shu)
Comment 16•11 years ago
|
||
From the patch, it looks like this only affects PJS, which is only enabled on trunk.
Assignee | ||
Comment 17•11 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #15)
> Shu: Before landing patches for security bugs please follow the process at
> https://wiki.mozilla.org/Security/Bug_Approval_Process
I've been told I only needed to do that for bugs that affect non-Nightly releases. Or was the problem that I didn't mark the other branches as unaffected?
Flags: needinfo?(shu)
Updated•10 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•