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.
=== 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?
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.
Created attachment 8795210 [details] [diff] [review] 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.
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Attachment #8795210 - Flags: review?(luke)
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/a14592c05e0f Handle OOM when calling inflate() with Z_NO_FLUSH. r=luke
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox52: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.