The following testcase crashes on mozilla-central revision a73077366144 (build with --enable-address-sanitizer --enable-more-deterministic, run with --fuzzing-safe --ion-offthread-compile=off --no-baseline --no-ion) with ASAN_OPTIONS=detect_leaks=1,exitcode=77 in the environment variable:

evalInWorker("");

Backtrace:

==33285==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x5575fbb07397 in __interceptor_malloc (/home/ubuntu/shell-cache/js-64-dm-asan-linux-x86_64-a73077366144/js-64-dm-asan-linux-x86_64-a73077366144+0x1457397)
#1 0x5575fbb93f07 in js_arena_malloc(unsigned long, unsigned long) /home/ubuntu/shell-cache/js-64-dm-asan-linux-x86_64-a73077366144/objdir-js/dist/include/js/Utility.h:367:10
#2 0x5575fbb93f07 in js_malloc(unsigned long) /home/ubuntu/shell-cache/js-64-dm-asan-linux-x86_64-a73077366144/objdir-js/dist/include/js/Utility.h:371
#3 0x5575fbb93f07 in js::Thread* js_new<js::Thread, js::Thread::Options&>(js::Thread::Options&) /home/ubuntu/shell-cache/js-64-dm-asan-linux-x86_64-a73077366144/objdir-js/dist/include/js/Utility.h:517
#4 0x5575fbb93f07 in EvalInWorker(JSContext*, unsigned int, JS::Value*) js/src/shell/js.cpp:4159
#5 0x5575fbd0bf42 in CallJSNative(JSContext*, bool ()(JSContext, unsigned int, JS::Value*), JS::CallArgs const&) js/src/vm/Interpreter.cpp:448:13
/snip

For detailed crash information, see attachment.

Jan, is this a valid issue? I only recently tried turning on LSan on the funfuzz fuzzers...

(build with --enable-address-sanitizer seems enough, --enable-more-deterministic isn't needed)

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/60cd2460476f
user: Nick Fitzgerald
date: Mon Aug 01 18:39:44 2016 -0700
summary: Bug 1290287 - Make js::HelperThread::thread a js::Thread instead of a PRThread; r=terrence

:fitzgen, is bug 1290287 a likely regressor?

It is quite possible!

Shell-only 64-byte memory leak. P3.

Gary, how important is it for us to fix small stuff like this? Can you easily ignore this particular leak, to get useful fuzzing results? Or is it a blocker?

I only just started testing LeakSanitizer recently, and this keeps popping out. I'd say this is a [fuzzblocker] in that it is benign, but that it keeps popping up very often. Moreover, while I can put in a suppression for this involving evalInWorker, I'd say that testing with evalInWorker with LeakSanitizer builds is mostly completely busted due to this. Also, It might mask other LeakSanitizer issues as well.

Hope this helps you figure out the priority.

https://hg.mozilla.org/mozilla-central/rev/138edceae4d9