User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20160209234513 Steps to reproduce: function f(x) { return x + x; } function dumpPaths(results) { results = results.map(paths => { return paths.map(path => { setJitCompilerOption("ion.warmup.trigger", 30); function f(a, b) { do { if (a == 0) return; a--; } while (true || this ? o.a-- : true); } f(200000, shortestPaths(this, [this], 200000)); }); }); } paths = shortestPaths(this, [f], 200000) dumpPaths(paths); Actual results: Assertion failure: isLive(), at js/src/build1/dist/include/js/HashTable.h:774 Segmentation fault (core dumped)

Decoder, is this a dupe of any of your bugs?

This uses a shell-only ubinode function so maybe it isn't security sensitive (bug 1249107 also involves this same method). Could you look at this please, Nick?

Will look into it.

I do not get any assertion failures or crashes. Any flags required? I just get a message about "o" being undefined within the condition of the do/while loop.

There a was line missing in the code I have submitted. Adding a statement "var o={}" will reproduce the crash

Spandan, I added `var o = {};` to the top of the script, and it still does not fail assertions nor crash. Can you share the full test case here as well as the flags you built the shell with and flags/environment variables you set when running the test? Thanks!

Build options : --enable-debug --enable-optimize --enable-posix-nspr-emulation --enable-valgrind

I haven't seen this issue at all, so it's not a duplicate to any of the LangFuzz bugs. I would assume the assertion is very sensitive to build options and maybe memory usage, so using the test with the exact build options/platform/os is probably crucial for reproduction.

I have pulled out the latest code base, and couldn't reproduce the code. My last checkout was in late march first week. It might have got fixed some where in between during development process. Generally, I refresh my code once in 15days. May be I should reduce this time frame to a week or less. Could anyone please suggest what would be idle time frame?

(In reply to Spandan Veggalam from comment #9) > I have pulled out the latest code base, and couldn't reproduce the code. > My last checkout was in late march first week. It might have got fixed some > where in between during development process. > Generally, I refresh my code once in 15days. May be I should reduce this > time frame to a week or less. Could anyone please suggest what would be idle > time frame? There have been a few fuzzbugs fixed related to shortestPaths, but I can't remember if any had this same crash signature. In general, I think it makes sense to see if the bug reproduces on the latest m-c when/before filing, but I defer to :decoder and :gkw.

We'll close this in a week if nobody can reproduce it.

Upon re-reading this report and bug 1249107, I am pretty confident this is a dupe of that one.