Restrict quit() argument to values 0-127

RESOLVED FIXED in mozilla38

Status

()

Core
JavaScript Engine
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: jandem, Assigned: jandem)

Tracking

unspecified
mozilla38
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
Created attachment 8553081 [details] [diff] [review]
Patch

This patch makes quit(x) throw if x is not in the range [0, 127].

decoder requested this to avoid false positives: when a script does quit(139) for instance, the fuzzer will think the shell segfaulted.
Attachment #8553081 - Flags: review?(jorendorff)
Comment on attachment 8553081 [details] [diff] [review]
Patch

Review of attachment 8553081 [details] [diff] [review]:
-----------------------------------------------------------------

The fuzzers should be able to tell the difference between an exit() and a crash without modifying the JS shell. At the POSIX level you're supposed to use wait(3) or waitpid(3) to monitor a process, and WIFSIGNALED() and WTERMSIG() to see if it was killed by a signal. If the fuzzer harnesses are written in Python or something, they can do the same; if they're written in bash it might be harder.

Limiting the status code to [0, 255] would be all right, since exit() masks away any higher bits anyway.

r=me if you still think it's best to land this.
Attachment #8553081 - Flags: review?(jorendorff) → review+
We have various harnesses. Some are Python but LangFuzz is Java and I think that kind of difference is not visible at the Java level anymore. There are also situations where the process runs on a different machine and the exit code is the only information transferred. So in general it would be good if that exit code was reliable :)
https://hg.mozilla.org/mozilla-central/rev/20f9a56f6928
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.