1323868 - Assertion failure: task->outOfMemory, at js/src/jscntxt.cpp:897

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

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

// jsfunfuzz-generated
startgc(8301);
offThreadCompileScript("(({a,b,c}))");
// Adapted from randomly chosen test: js/src/jit-test/tests/debug/bug1109328.js
gcparam("maxBytes", gcparam("gcBytes"));


Backtrace:

0   libsystem_kernel.dylib        	0x00007fffb2792c86 __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fffb287c96a _pthread_cond_wait + 712
2   js-dbg-64-dm-clang-darwin-489f981e8c2b	0x0000000106a2b87b js::ConditionVariable::wait_for(js::LockGuard<js::Mutex>&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) + 59 (ConditionVariable.cpp:118)
3   js-dbg-64-dm-clang-darwin-489f981e8c2b	0x00000001070edc3f js::CancelOffThreadParses(JSRuntime*) + 575 (HelperThreads.h:287)
4   js-dbg-64-dm-clang-darwin-489f981e8c2b	0x0000000107172c3e JSRuntime::destroyRuntime() + 270 (Runtime.cpp:398)
/snip

For detailed crash information, see attachment.

This seems like an OOM bug but startgc is involved, so setting s-s to be safe as a start.

Comment 1

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

Attachment: Detailed Crash Information

Comment 2

[Fuzzing Team]

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Comment 3

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/47d405339a6f
user:        Tom Schuster
date:        Sat Nov 26 19:01:17 2016 +0100
summary:     Bug 1192038 - Use ordinary object for RegExp prototype. r=arai,jandem

Tom, is bug 1192038 a likely regressor?

Comment 4

[Tom S. (please needinfo tschuster)]

Bug 1192038 changes the way we allocate the prototype, so it does seem likely this was somehow caused by this. Bug 1319952 mighht be similar in that changing the prototype allocation was causing unexpected issues with offthread parsing. We really need to get type safety here ..
I can't look into this before Sunday though.

Comment 5

[Jon Coppeard (:jonco)]

Attachment: bug1323868-report-alloc-oom

The problem is that we can call GCRuntime::tryNewTenuredObject<NoGC> from js::Allocate<JSObject, CanGC>.  As well as controlling whether GC can happen, AllowGC parameter also controls whether we report errors (because in some places we try to allocate without the possibility of GC first and then retry if that fails).

In this case we need to check and report the error here.

Note GCRuntime::tryNewTenuredThing already does this where it calls the NoGC version of itself at Allocator.cpp:176.

I don't think this is security sensitive.

Comment 6

[Jan de Mooij [:jandem]]

Comment on attachment 8819940 [details] [diff] [review]
bug1323868-report-alloc-oom

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

::: js/src/gc/Allocator.cpp
@@ +39,5 @@
>      MOZ_ASSERT_IF(nDynamicSlots != 0, clasp->isNative() || clasp->isProxy());
>  
>      // Off-main-thread alloc cannot trigger GC or make runtime assertions.
> +    if (!cx->isJSContext()) {
> +        JSObject *obj = GCRuntime::tryNewTenuredObject<NoGC>(cx, kind, thingSize, nDynamicSlots);

Nit: JSObject* obj

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f425430a6703
Report object allocation failure when running off-main-thread r=jandem

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f425430a6703