Crash [@ PodAssign<char16_t>] or [@ js::CurrentThreadCanAccessRuntime]

VERIFIED FIXED in Firefox 29

Status

()

--
critical
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: gkw, Assigned: bhackett)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla30
x86_64
All
crash, regression, sec-high, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox28 unaffected, firefox29 fixed, firefox30 fixed, firefox-esr24 unaffected)

Details

(Whiteboard: [fuzzblocker][jsbugmon:origRev=6c899a1064f3], crash signature)

Attachments

(1 attachment, 1 obsolete attachment)

Created attachment 8372678 [details]
stack

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)
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]
Crash Signature: [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime]
Whiteboard: [jsbugmon:update] → [jsbugmon:]
JSBugMon: Cannot process bug: Error: Failed to compile specified revision 262e73a6b7cd (maybe try another?)
(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]
Crash Signature: [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime]
Whiteboard: [jsbugmon:update,origRev=6c899a1064f3] → [jsbugmon:origRev=6c899a1064f3]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Crash Signature: [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime]
Keywords: sec-high
This is a fairly common occurrence for threadsafe builds.
Whiteboard: [jsbugmon:origRev=6c899a1064f3] → [fuzzblocker][jsbugmon:origRev=6c899a1064f3]
status-firefox30: --- → affected
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: --- → ?
OS: Linux → All
(Assignee)

Comment 7

5 years ago
Can you attach stacks for all threads when this crash is hit?  I can't reproduce it.
Flags: needinfo?(bhackett1024)
Created attachment 8380009 [details]
thread apply all bt

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

5 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)
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-firefox30: affected → fixed
tracking-firefox30: ? → ---
Resolution: --- → FIXED
> 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.
Status: RESOLVED → VERIFIED
Crash Signature: [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime]
JSBugMon: This bug has been automatically verified fixed.
Assignee: nobody → bhackett1024
Crash Signature: [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime] → [@ PodAssign<char16_t>] [@ js::CurrentThreadCanAccessRuntime]
status-firefox28: --- → unaffected
status-firefox29: --- → fixed
Target Milestone: --- → mozilla30
status-firefox-esr24: --- → unaffected
Group: core-security
You need to log in before you can comment on or make changes to this bug.