Bugzilla

We get the occasional security bug filed by an external reporter about a issue that happens after the (ContentChild::ActorDestroy QuickExist)[https://searchfox.org/mozilla-central/rev/4e22b886bbd4c274f268c4a285ab7da00e95c99b/dom/ipc/ContentChild.cpp#2177], which should not be exploitable in opt builds. It would be nice if we could avoid these to reduce bug reporter frustration.

Currently we make ASan builds NS_FREE_PERMANENT_DATA because we use them for LeakSanitizer, but fuzzing ASan builds are not being used for leak checking (because we already have more test cases for leaks than we're able to fix...), so we should probably not use NS_FREE_PERMANENT_DATA for them. The builds already have to be separate because they define FUZZING so this shouldn't be hard. Maybe we could be smarter and specifically check if LSan is running but there's probably no need to get that fancy.

I was talking to jkratzer about this, and it sounds like when fuzzing a test case gets opened in a new tab and only runs for like 30 seconds, so in addition to reducing reports that aren't very useful, it should also make fuzzing a little faster.

One concern that Jason raised is that we might miss some issues that only show up after the shutdown GC/CC, because they don't always do that themselves while fuzzing. It might be interesting to look back at fuzzing bugs with ASan reports to see how many have XPCOM shutdown or whatever in the stack, which should be doable with a careful bugzilla search.

We get the occasional security bug filed by an external reporter about a issue that happens after the [ContentChild::ActorDestroy QuickExit](https://searchfox.org/mozilla-central/rev/4e22b886bbd4c274f268c4a285ab7da00e95c99b/dom/ipc/ContentChild.cpp#2177), which should not be exploitable in opt builds. It would be nice if we could avoid these to reduce bug reporter frustration.

Currently we make ASan builds NS_FREE_PERMANENT_DATA because we use them for LeakSanitizer, but fuzzing ASan builds are not being used for leak checking (because we already have more test cases for leaks than we're able to fix...), so we should probably not use NS_FREE_PERMANENT_DATA for them. The builds already have to be separate because they define FUZZING so this shouldn't be hard. Maybe we could be smarter and specifically check if LSan is running but there's probably no need to get that fancy.

I was talking to jkratzer about this, and it sounds like when fuzzing a test case gets opened in a new tab and only runs for like 30 seconds, so in addition to reducing reports that aren't very useful, it should also make fuzzing a little faster.

One concern that Jason raised is that we might miss some issues that only show up after the shutdown GC/CC, because they don't always do that themselves while fuzzing. It might be interesting to look back at fuzzing bugs with ASan reports to see how many have XPCOM shutdown or whatever in the stack, which should be doable with a careful bugzilla search.