Closed
Bug 969702
Opened 10 years ago
Closed 10 years ago
Crash [@ PodAssign<char16_t>] or [@ js::CurrentThreadCanAccessRuntime]
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
VERIFIED
FIXED
mozilla30
Tracking | Status | |
---|---|---|
firefox28 | --- | unaffected |
firefox29 | --- | fixed |
firefox30 | --- | fixed |
firefox-esr24 | --- | unaffected |
People
(Reporter: gkw, Assigned: bhackett1024)
References
Details
(4 keywords, Whiteboard: [fuzzblocker][jsbugmon:origRev=6c899a1064f3])
Crash Data
Attachments
(1 file, 1 obsolete file)
40.88 KB,
text/plain
|
Details |
var x; evalcx("y+z", x); crashes js debug shell on m-c changeset 262e73a6b7cd with --ion-parallel-compile=off --ion-eager --ion-check-thread-safety at PodAssign<char16_t> s-s because this signature seems scary. This crash is intermittent and crashes Ubuntu Linux 12.04 LTS about once in 5-10 times for me. My configure flags are: AR=ar sh ./configure --enable-optimize --enable-debug --enable-profiling --enable-gczeal --enable-debug-symbols --enable-methodjit --enable-type-inference --disable-tests --enable-more-deterministic --enable-exact-rooting --with-ccache --enable-threadsafe <other NSPR options> autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/995f7402235b user: Brian Hackett date: Wed Feb 05 11:40:35 2014 -0700 summary: Bug 941805 - Make the pool of JS workers be per process rather than per runtime, r=billm. Brian, is bug 941805 a likely regressor?
Flags: needinfo?(bhackett1024)
Reporter | ||
Comment 1•10 years ago
|
||
Sometimes the crash signature is at js::CurrentThreadCanAccessRuntime.
Crash Signature: [@ PodAssign<char16_t>] → [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime]
Summary: Crash [@ PodAssign<char16_t>] → Crash [@ PodAssign<char16_t>] or [@ js::CurrentThreadCanAccessRuntime]
Updated•10 years ago
|
Crash Signature: [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime]
Whiteboard: [jsbugmon:update] → [jsbugmon:]
Comment 2•10 years ago
|
||
JSBugMon: Cannot process bug: Error: Failed to compile specified revision 262e73a6b7cd (maybe try another?)
Reporter | ||
Comment 3•10 years ago
|
||
(In reply to Christian Holler (:decoder) from comment #2) > JSBugMon: Cannot process bug: Error: Failed to compile specified revision > 262e73a6b7cd (maybe try another?) Retry with a later revision that fixed non-threadsafe build compilation issues.
Crash Signature: [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime]
Whiteboard: [jsbugmon:] → [jsbugmon:update,origRev=6c899a1064f3]
Updated•10 years ago
|
Crash Signature: [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime]
Whiteboard: [jsbugmon:update,origRev=6c899a1064f3] → [jsbugmon:origRev=6c899a1064f3]
Comment 4•10 years ago
|
||
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Updated•10 years ago
|
Crash Signature: [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime]
Keywords: sec-high
Reporter | ||
Comment 5•10 years ago
|
||
This is a fairly common occurrence for threadsafe builds.
Whiteboard: [jsbugmon:origRev=6c899a1064f3] → [fuzzblocker][jsbugmon:origRev=6c899a1064f3]
Reporter | ||
Updated•10 years ago
|
status-firefox30:
--- → affected
Reporter | ||
Comment 6•10 years ago
|
||
Passing the --no-sse3 or the --no-sse4 flags into the Windows 64-bit debug shell, e.g.: ./js --no-sse3 -e 42 can also occasionally (once in ~30 times) result in a crash (non-zero exit code 253). autoBisect also reduced this to: The first bad revision is: changeset: http://hg.mozilla.org/mozilla-central/rev/995f7402235b user: Brian Hackett date: Wed Feb 05 11:40:35 2014 -0700 summary: Bug 941805 - Make the pool of JS workers be per process rather than per runtime, r=billm.
tracking-firefox30:
--- → ?
Reporter | ||
Updated•10 years ago
|
OS: Linux → All
Assignee | ||
Comment 7•10 years ago
|
||
Can you attach stacks for all threads when this crash is hit? I can't reproduce it.
Flags: needinfo?(bhackett1024)
Reporter | ||
Comment 8•10 years ago
|
||
I could reproduce this on the original specified changeset with --ion-check-thread-safety.
Attachment #8372678 -
Attachment is obsolete: true
Flags: needinfo?(bhackett1024)
Assignee | ||
Comment 9•10 years ago
|
||
Hmm, it looks like the memory protection done by --ion-check-thread-safety is causing this crash --- the main thread is compiling a script and has protected the GC heap, and another thread is doing source compression and trying to use a string's inline chars for the script source. This behavior is fine and just an issue with debugging code, and since --ion-check-thread-safety has been removed there isn't anything more to be done here. I don't know what the problem with the Windows 64 bit crash is but it's a separate issue and there isn't much to go on without a stack trace.
Flags: needinfo?(bhackett1024)
Reporter | ||
Comment 10•10 years ago
|
||
The Win64-debug crash is perhaps the same issue, but I can always open a new bug if it happens again. Since the issue in comment 0 has likely been fixed by the backout let's just call this fixed for now.
Reporter | ||
Comment 11•10 years ago
|
||
> and since --ion-check-thread-safety has been removed there isn't anything more to be > done here. For the record, this was removed in bug 785905.
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
Crash Signature: [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime]
Comment 12•10 years ago
|
||
JSBugMon: This bug has been automatically verified fixed.
Updated•10 years ago
|
Assignee: nobody → bhackett1024
Crash Signature: [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>]
[@ js::CurrentThreadCanAccessRuntime]
status-firefox28:
--- → unaffected
status-firefox29:
--- → fixed
Target Milestone: --- → mozilla30
Updated•10 years ago
|
status-firefox-esr24:
--- → unaffected
Updated•9 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•