1493475 - Assertion failure: !markCount, at js/src/ds/LifoAlloc.h:783

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The following testcase crashes on mozilla-central revision 221c18ebe962 (build with --enable-debug --enable-more-deterministic, run with --fuzzing-safe --no-baseline --no-ion):

offThreadCompileScript("\
    (function(stdlib, foreign) {\
        \"use asm\";\
        function() {};\
    })();\
");

Backtrace:

#0  0x0000557fd2c75f24 in js::LifoAlloc::releaseAll (this=0x7f50350019e0) at js/src/ds/LifoAlloc.h:783
#1  0x0000557fd33d21a4 in js::HelperThread::maybeFreeUnusedMemory (this=<optimized out>, cx=<optimized out>) at js/src/vm/HelperThreads.cpp:2623
#2  js::HelperThread::threadLoop (this=0x7f5035604d80) at js/src/vm/HelperThreads.cpp:2581
#3  0x0000557fd33ce39d in js::HelperThread::ThreadMain (arg=0x7f50367b9680 <_IO_2_1_stderr_>) at js/src/vm/HelperThreads.cpp:2020
#4  0x0000557fd33ffa3f in js::detail::ThreadTrampoline<void (&)(void*), js::HelperThread*>::callMain<0ul> (this=0x7f5035619080) at js/src/threading/Thread.h:243
/snip

For detailed crash information, see attachment.

Memory allocation may be involved, so setting s-s as a start.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Detailed Crash Information

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/7a9384b6a6c9
user:        Jon Coppeard
date:        Tue Sep 18 13:56:45 2018 +0100
summary:     Bug 1491037 - Periodically free helper thread LifoAlloc memory r=nbp

Jon, is bug 1491037 a likely regressor?

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Setting [fuzzblocker] as this seems to be happening quite frequently.

Comment 4

[Ted Campbell [:tcampbell]]

Attachment: Cleanup asm.js parser cleanup

Comment 5

[Ted Campbell [:tcampbell]]

Error path for asm.js parse verification creates a mark but doesn't cleanup the mark. This screws up the mark count checks.

Side effects are this debug assert, some memory cleanup heuristics won't work (but this won't come up on well-formed script), and ParserBase::traceListHead won't get restored. This should all be fine since this was added as a perf/mem optimization. Probably can open this bug (I'll wait for review first).

Comment 6

[Luke Wagner [:luke]]

Comment on attachment 9011635 [details] [diff] [review]
Cleanup asm.js parser cleanup

Review of attachment 9011635 [details] [diff] [review]:
-----------------------------------------------------------------

Whoa, this bug is ancient (https://hg.mozilla.org/mozilla-central/rev/541c383c1698)!  So I guess, before this patch, there simply were never freeAll() calls on the parser's LifoAlloc.  A long time ago I added freeAllIfHugeAndUnused() (https://hg.mozilla.org/mozilla-central/file/7a9384b6a6c9/js/src/frontend/Parser.cpp#l953) but of course a leaked markCount prevents it from freeing all.

It really seems like ~Mark() should own the markCount (releasing itself in the dtor or at least asserting that it has been released), but this seems like the right quick fix.

Comment 7

[Ted Campbell [:tcampbell]]

Unhiding and landing testcase with it.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b553d15956a
Cleanup asm.js parser cleanup. r=luke

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/beb1b19a7ea1
Fixup broken test. r=bustage

Comment 10

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/8b553d15956a
https://hg.mozilla.org/mozilla-central/rev/beb1b19a7ea1

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Is this something we need to worry about backporting or can it ride the trains?

Comment 12

[Ted Campbell [:tcampbell]]

Ride the trains. This is not a sec issue, affected code is years old, and it surfaced to fuzzing only because of better tooling that landed in FF64.