Going further from the previous changes, all libfuzzer_main really does
is call the init function, and then proceed to call the fuzzer driver
with the testing function.
So instead of calling that function for it to do all that, the
LibFuzzerRunner can just call the init function itself, and then
call the fuzzer driver with the testing function.
The LibFuzzerRunner code lives in libxul. It's unnecessary complications
to have it call back a function in the firefox executable just so that
it calls another function that is in libxul. Passing the init and
testing functions to the libfuzzer_main function allows to just bypass
that roundtrip, simplifying the setup.
The function given to XRE_LibFuzzerSetMain is called from somewhere that
does have access to argc/argv already, so we can avoid passing them
to XRE_LibFuzzerSetMain.
This actually might fix subtle issues with argc/argv not really matching
reality when calling the LibFuzzerMain function in the current code:
some arguments are handled before the call, and both argc and argv are
modified from within XRE_main, but the values stored for the
LibFuzzerMain call still are the original ones.
Argv being a pointer, and it not being reallocated, the value stored for
the LibFuzzerMain call points to the changed one, but argc, being an
integer, is not modified accordingly.
In fact, it's actually worse, because while the Gecko code doesn't
reallocate argv, gtk_main might. So if some GTK flag is passed on the
command line, there's also a possibility that the LibFuzzerMain function
will do a use-after-free.
So all in all, it's just better to use the set of modified argc/argv
from XRE_main instead of storing them from main().
Reading application.ini involves using nsCOMPtr<nsIFile>, and that can
only happen through the XPCOM glue, which we eventually want to get rid
of.
So, while keeping the command line argument/environment variable
handling in nsBrowserApp, we move the actually parsing of the file to
XRE_main, where things can be handled without the XPCOM glue.
Instead of having nsBrowserApp.cpp set a flag in XREAppData to indicate
whether the DLL blocklist properly initialized, just have XRE code ask
the blocklist itself.
Back in bug 632404, when the function was added, preloading was
conditional. But after some A/B testing, the conclusion in bug 771745
was that we would just do preloading unconditionally.
Which means in practice, we don't need to have a function to enable it
manually anymore, since we're always enabling it.
MacQuirks was targeted for OSX from 10.6.8 up to but not including 10.7.0. We
have now removed support for 10.6 so we can safely remove this code. This also
fixes bug 1282184 where DMD is apparently choking on memory allocated in the
interpose library.
MacQuirks was targeted for OSX from 10.6.8 up to but not including 10.7.0. We
have now removed support for 10.6 so we can safely remove this code. This also
fixes bug 1282184 where DMD is apparently choking on memory allocated in the
interpose library.
Before bug 552864, the string was created with PR_smprintf, and
PR_SetEnv'ed (which, under the hood, just calls putenv). PR_smprintf was
allocating the string on the heap. Now, it's allocated on the stack, and
still putenv'ed.
putenv kind of takes ownership of the strings it's being passed, so
stack allocated strings are dangerous to use. It looks like we've been
fairly lucky that it worked, presumably because compilers would keep the
stack frame with the variable, but that's not guaranteed to happen, and
in some case, doesn't.
So we strdup the string and purposefully leak it instead, which matches
what happened before bug 552864, and is the only "sane" way to use
putenv.
Disabled on Mac (content processes need to use plugin-container.app for
UI reasons) and on Linux unless --disable-sandboxing (build issues).
Based on work by George Wright <george@mozilla.com>.
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
