After funfuzz found "Assertion failure", what should I do?

[ghost]

Hi. There is no documentation which explained what user should do after funfuzz finds Assertion failure.

I am studying fuzzing, but fuzzing is really hard to learn...:( I hope you will reply to this question.

---

Step to reproduce

1. run a command

python -u funfuzz/loopBot.py -b "--random" -t "js" --target-time 28800 | tee ~/log-loopBotPy.txt

1. funfuzz finds Assertion failure

My question: Is funfuzz still fuzzing after funfuzz detected Assertion failure?

---

message is like this....

ReportOutOfMemory called ReportOutOfMemory called ReportOutOfMemory called ReportOutOfMemory called ReportOutOfMemory called ReportOutOfMemory called ReportOutOfMemory called ReportOutOfMemory called Assertion failure: (source file & code line)

[ghost]

Will funfuzz stop funfuzz detected Assertion failure? If so, how do I keep fuzzing?

[nth10sd]

When you setup funfuzz, it is recommended to also set up an instance of FuzzManager: https://github.com/mozillasecurity/fuzzmanager

Point the .fuzzmanagerconf to your own instance.

Once the assertion failure is detected, funfuzz should automatically reduce them and report to your fuzzmanager instance. The reduced files are found in the temp folder locations, e.g. /tmp/fuzzbot* and will be uploaded to that instance.

Finally, file the bug w/ the reduced testcase in Bugzilla, also listing the mozilla-central (or whatever branch) build revision hash and the build configuration of the js shell as well.

[ghost]

"ReportOutOfMemory called"

This message was displayed because I failed to set up FuzzManager?

Thank you for fast reply.

[nth10sd]

Nope. You might have found an actual bug. That message is displayed because jsfunfuzz generated a testcase that causes the shell to enter a simulated OOM condition, the "Assertion failure: ..." message is the interesting bit.

We are interested in the testcases which show "Assertion failure: ..." - please file this with the full assertion failure message but check for dupes first:

https://bugzilla.mozilla.org/query.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component=JavaScript%20Engine&component=JavaScript%20Engine:%20JIT&component=JavaScript:%20GC&component=JavaScript:%20Internationalization%20API&component=JavaScript:%20Standard%20Library&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&j_top=AND&f1=noop&o1=noop&v1=

(enter the Assertion failure message in the summary/comment box)

[nth10sd]

Not setting up FuzzManager means you wouldn't have a one-stop place to look over all your fuzzing results.

[ghost]

I will file a bug soon, but to tell you the truth... where should I report? There are so many branch on bugzilla. Seamonkey? Core? I am so sorry for asking a stupid question.

[ghost]

Sorry... my issue has been already reported...

https://bugzilla.mozilla.org/show_bug.cgi?id=1269074

[nth10sd]

No questions are stupid! :)

Bugs found by jsfunfuzz are likely to go into Core -> JavaScript Engine, if you are not sure, file it there and hopefully someone will take over. Be sure to enter "349611" into the "Blocks" field to add it to the jsfunfuzz meta bug.

[nth10sd]

So in this scenario, if FuzzManager was set up, a bucket could be created for this pointing to that bug, and the harness will then no longer treat this particular assertion failure message as "interesting".

[ghost]

After comparing my report and your report, I noticed that user and revision are different, but Assertion failure is the same. This happened because the route cause is the same?

[nth10sd]

I'd say likely yes. Most of the time, if the assertion failure messages are the same, it's probably the same root cause.

However, there are some cases where the stacks are different, or it could be a certain type of message that has many root causes (e.g. "Assertion failure: !cx->isExceptionPending()" ). Thus, as you start off creating buckets, it would be wise to double check first, probably with the SpiderMonkey js developers.

Hop on to irc.mozilla.org and feel free to ask in #fuzzing or #jsapi/#ionmonkey. Note that we are mostly in the North American / European timezones, though some of us sometimes stay up late. :)