1305570 - Assertion failure: ret == 0, at js/src/vm/Compression.cpp:242

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

The following testcase crashes on mozilla-central revision c55bcb7c777e (build with --enable-debug, run with --fuzzing-safe --ion-offthread-compile=off --no-baseline --ion-eager):

See attachment.

Backtrace:

1   js-dbg-64-clang-darwin-c55bcb7c777e	0x0000000100bc0844 js::ScriptSource::chunkChars(JSContext*, js::UncompressedSourceCache::AutoHoldEntry&, unsigned long) + 372 (jsscript.cpp:1552)
2   js-dbg-64-clang-darwin-c55bcb7c777e	0x0000000100bc0aeb js::ScriptSource::chars(JSContext*, js::UncompressedSourceCache::AutoHoldEntry&, unsigned long, unsigned long) + 187 (jsscript.cpp:1601)
3   js-dbg-64-clang-darwin-c55bcb7c777e	0x0000000100bbf9bc js::ScriptSource::substring(JSContext*, unsigned long, unsigned long) + 76 (jsscript.cpp:1658)
4   js-dbg-64-clang-darwin-c55bcb7c777e	0x0000000100b1f48d js::FunctionToString(JSContext*, JS::Handle<JSFunction*>, bool) + 941 (RootingAPI.h:700)
/snip

For detailed crash information, see attachment.

Setting [fuzzblocker] because this is happening fairly often.

Comment 1

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

Attachment: Detailed Crash Information

Comment 2

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

Attachment: Testcase

Comment 3

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

=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160923033900" and the hash "c4d91d17c8ed2e385f4a4a3d97f861eee722626f".
The "bad" changeset has the timestamp "20160923040159" and the hash "52459cfd15765aa82ff26501b9c1a56272d49f0d".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c4d91d17c8ed2e385f4a4a3d97f861eee722626f&tochange=52459cfd15765aa82ff26501b9c1a56272d49f0d

Jan, is bug 1304390 a likely regressor?

Comment 4

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

Note that this can be a little intermittent though still fairly reproducible. The more I reduce the testcase, the less reproducible it becomes, so the testcase is fairly large, and setting JSBugMon to ignore.

Comment 5

[Jan de Mooij [:jandem]]

Attachment: Patch

This is annoying:

When inflate() is called with flush = Z_FINISH parameter, it won't allocate any memory. However, we can't use Z_FINISH for chunks other than the last one, or inflate() will throw Z_BUF_ERROR at us.

So for these non-last chunks, we have to use Z_NO_FLUSH (or Z_BLOCK, it doesn't really matter). When zlib is done, it attempts to allocate some internal (window) data structures for the *next* call to inflate. In this case there won't be another call to inflate (we immediately call inflateEnd), but unfortunately there's no way to communicate that to zlib.

Anyway, let's just handle OOM return values from inflate() in this case. I also upgraded some asserts to release asserts.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a14592c05e0f
Handle OOM when calling inflate() with Z_NO_FLUSH. r=luke

Comment 7

[Carsten Book [:Tomcat]]

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