Crash [@ JS::LossyTwoByteCharsToNewLatin1CharsZ] or Assertion failure: startOffset_ <= offset, at frontend/TokenStream.h

RESOLVED FIXED in mozilla36

Status

()

--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: gkw, Assigned: jimb)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla36
assertion, crash, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox36 affected)

Details

(Whiteboard: [jsbugmon:update,origRev=ab137ddd3746], crash signature)

Attachments

(3 attachments)

options('strict');
function eval() {};
eval();

asserts js debug shell on m-c changeset eb0d3b3c0b22 with --no-ion --no-threads at Assertion failure: startOffset_ <= offset, at frontend/TokenStream.h.

Debug configure options:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/bc7884c686bc
user:        Jim Blandy
date:        Wed Nov 12 14:51:40 2014 -0800
summary:     Bug 1083913: Make js::TokenStream::TokenBuf store the starting offset of its buffer explicitly, not implicitly as a bias on base_. r=shu

Jim, is bug 1083913 a possible regressor?
Flags: needinfo?(jimb)
Whiteboard: [jsbugmon:update] → [jsbugmon:]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Got the m-c rev wrong, it should be ab137ddd3746.
Whiteboard: [jsbugmon:] → [jsbugmon:update,origRev=ab137ddd3746]
(Assignee)

Comment 3

4 years ago
Well, bug 1083913 added the assertion, but it almost certainly is catching a real error.
Flags: needinfo?(jimb)
(Assignee)

Comment 4

4 years ago
I can reproduce the crash.
Created attachment 8522671 [details]
stack

(lldb) bt 5
* thread #1: tid = 0x18e2d1, 0x000000010017cef1 js-dbg-opt-64-dm-nsprBuild-darwin-ab137ddd3746`js::frontend::TokenStream::TokenBuf::rawCharPtrAt(this=<unavailable>, offset=<unavailable>) const + 193 at TokenStream.h:692, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010017cef1 js-dbg-opt-64-dm-nsprBuild-darwin-ab137ddd3746`js::frontend::TokenStream::TokenBuf::rawCharPtrAt(this=<unavailable>, offset=<unavailable>) const + 193 at TokenStream.h:692
    frame #1: 0x0000000100138818 js-dbg-opt-64-dm-nsprBuild-darwin-ab137ddd3746`js::frontend::TokenStream::reportCompileErrorNumberVA(unsigned int, unsigned int, unsigned int, __va_list_tag*) [inlined] js::frontend::TokenStream::TokenBuf::findEOLMax(this=0x00007fff5fbfdaf8, start=0, max=<unavailable>) + 8 at TokenStream.cpp:508
    frame #2: 0x0000000100138810 js-dbg-opt-64-dm-nsprBuild-darwin-ab137ddd3746`js::frontend::TokenStream::reportCompileErrorNumberVA(this=0x00007fff5fbfd818, offset=<unavailable>, flags=<unavailable>, errorNumber=<unavailable>, args=<unavailable>) + 848 at TokenStream.cpp:706
    frame #3: 0x0000000100138e19 js-dbg-opt-64-dm-nsprBuild-darwin-ab137ddd3746`js::frontend::TokenStream::reportStrictModeErrorNumberVA(this=<unavailable>, offset=<unavailable>, strictMode=<unavailable>, errorNumber=<unavailable>, args=<unavailable>) + 41 at TokenStream.cpp:587
    frame #4: 0x0000000100039c49 js-dbg-opt-64-dm-nsprBuild-darwin-ab137ddd3746`js::frontend::Parser<js::frontend::FullParseHandler>::report(js::frontend::ParseReportKind, bool, js::frontend::ParseNode*, unsigned int, ...) [inlined] js::frontend::Parser<js::frontend::FullParseHandler>::reportHelper(this=<unavailable>, kind=<unavailable>, offset=<unavailable>, errorNumber=<unavailable>) + 249 at Parser.cpp:434
(lldb)
(Assignee)

Comment 6

4 years ago
Thanks, Gary --- actually, I'm all set. I can reproduce it locally, and I'm actively working on debugging it.
(Assignee)

Updated

4 years ago
Assignee: nobody → jimb
Status: NEW → ASSIGNED
(Assignee)

Comment 7

4 years ago
The bug here is that Parser<FullParseHandler>::standaloneLazyFunction constructs a parse node without ever having fetched the next token. The node is assigned zero as its starting offset, which, in the case of lazy function compilation, is off the beginning of the buffer.

This is not S-S, as lazy compilation always in fact brings the full source into memory before compiling some substring of it, so there is indeed text at offset zero; it's just outside the range that the compiler officially knows about, hence the assertion.

Fix should be quick.
Created attachment 8523700 [details]
stack for opt crash

eval("\
    x1 = {};\
    x2 = this;\
    Uint8ClampedArray;\
    x1.p = wrap(this);\
    function eval() {};\
    options('strict');\
    Set(x1);\
")

Here's a variant that crashes js opt shell on m-c rev a52bf59965a0 with --no-threads --no-ion at JS::LossyTwoByteCharsToNewLatin1CharsZ and asserts similarly.

If you mention this is unlikely to be s-s, I hope this testcase isn't trying to something bad at weird memory address 0x02a1aa00.
Flags: needinfo?(jimb)
The shell in comment 8 that crashes is 32-bit:

LD=ld CROSS_COMPILE=1 CC="clang -Qunused-arguments -msse2 -mfpmath=sse -arch i386" RANLIB=ranlib CXX="clang++ -Qunused-arguments -msse2 -mfpmath=sse -arch i386" AS=$CC AR=ar STRIP="strip -x -S" HOST_CC="clang -Qunused-arguments -msse2 -mfpmath=sse" AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 HOST_CXX="clang++ -Qunused-arguments -msse2 -mfpmath=sse" sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=i386-apple-darwin9.2.0 --enable-macos-target=10.5 --disable-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

A 64-bit opt shell, instead of crashing, shows:

js-dbgDisabled-opt-64-dm-nsprBuild-darwin-a52bf59965a0(64216,0x7fff7a83c300) malloc: *** mach_vm_map(size=9223372036854775808) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
js-dbgDisabled-opt-64-dm-nsprBuild-darwin-a52bf59965a0(64216,0x7fff7a83c300) malloc: *** mach_vm_map(size=9223372036854775808) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
js_ReportOutOfMemory called
uncaught exception: out of memory
Crash Signature: [@ JS::LossyTwoByteCharsToNewLatin1CharsZ]
Keywords: crash
Summary: Assertion failure: startOffset_ <= offset, at frontend/TokenStream.h → Crash [@ JS::LossyTwoByteCharsToNewLatin1CharsZ] or Assertion failure: startOffset_ <= offset, at frontend/TokenStream.h
(Assignee)

Comment 10

4 years ago
Created attachment 8524036 [details] [diff] [review]
Correctly set the source position of the function's parse node when parsing lazy functions.

This fixes the first crash. I'm not able to reproduce the second.
Flags: needinfo?(jimb)
Attachment #8524036 - Flags: review?(jwalden+bmo)
(Assignee)

Updated

4 years ago
Attachment #8524036 - Flags: review?(jwalden+bmo) → review?(luke)

Updated

4 years ago
Attachment #8524036 - Flags: review?(luke) → review+
(Assignee)

Comment 12

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d9c788855be
Flags: in-testsuite+
OS: Mac OS X → All
Hardware: x86_64 → All
Target Milestone: --- → mozilla36
https://hg.mozilla.org/mozilla-central/rev/9d9c788855be
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.