Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : 4d5637bcdbeae605b0b99e9192598d48f371b698
Hook this into the browser via the XREAppData. This patch does not include the changes to Chromium source code.
--HG--
extra : rebase_source : e34e8b50101cc40ded26e80791052123b24c8243
extra : histedit_source : 69c9b2dc91546adbfdad03b5d43842809191ffb9
The FileExists check can be removed because the code loading the library
will handle that case already.
--HG--
extra : rebase_source : bac53d3f88ed1dd716ee1340d40dae42becdfdf0
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.
--HG--
extra : rebase_source : 2eb1a2ae763ef21827471cd32addceacefc1ac5d
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.
--HG--
extra : rebase_source : ba72c029a904e05fe3b0ed5984c1bad946b73c6a
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().
--HG--
extra : rebase_source : 92b89909eab0fc2f67ce372b959bb0e3ed12cd2b
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.
--HG--
extra : rebase_source : 487960a671476d4edae4f568c37efa6563ef4dff
This just wraps all the XRE method calls to go through the Bootstrap API
instead of relying on the XPCOM glue methods.
--HG--
extra : rebase_source : eccbe18b9b21ca1ab6c403515ffd60f0a9174d9c
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.
--HG--
extra : rebase_source : e872853481acce68b325909e476d009aec878701
This hasn't been used since the removal of the Metro code in bug
1039866, close to two years ago.
--HG--
extra : rebase_source : 58ec1ce63e4231c8006cafd3424675f14ddbf9f1
It turns out nsAppRunner.cpp sets it to the exact same thing when it's
not already set, so we might as well use that.
--HG--
extra : rebase_source : cb8955e75c13a02494f3e163089c53696a661aa9
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.
--HG--
extra : rebase_source : c76307c13c057e87e1fe4564b82113fbfa20d382
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.
--HG--
extra : rebase_source : e39349f90f5346b591e20696c0c3c7fdb26c3cfb
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>.
--HG--
extra : amend_source : 43986e25743de21e3ddfb7893e3ed550fe6eef76
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.
Benjamin Smedberg
David Parks
Sebastian Hengst
Phil Ringnalda
Mike Hommey
Jed Davis
Henri Sivonen
Tom Schuster
Christian Holler (:decoder)
Jorg K
Jim Mathies
Aaron Klotz
Eric Rahm
Makoto Kato
Chris Peterson
Andrea Marchesini
Carsten "Tomcat" Book
Bob Owen
Gabriele Svelto