Closed Bug 1098132 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox36 --- affected

People

(Reporter: gkw, Assigned: jimb)

References

Details

(4 keywords, Whiteboard: [jsbugmon:update,origRev=ab137ddd3746])

Crash Data

Attachments

(3 files)

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]
Well, bug 1083913 added the assertion, but it almost certainly is catching a real error.
Flags: needinfo?(jimb)
I can reproduce the crash.
Attached file 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)
Thanks, Gary --- actually, I'm all set. I can reproduce it locally, and I'm actively working on debugging it.
Assignee: nobody → jimb
Status: NEW → ASSIGNED
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.
Attached file 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
This fixes the first crash. I'm not able to reproduce the second.
Flags: needinfo?(jimb)
Attachment #8524036 - Flags: review?(jwalden+bmo)
Attachment #8524036 - Flags: review?(jwalden+bmo) → review?(luke)
Attachment #8524036 - Flags: review?(luke) → review+
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
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.