__wrap_dlerror uses a single pointer for all threads, which means one
thread could get the dlerror result from another thread. Normally this
wouldn't cause crashes. However, because dlerror results come from a
per-thread buffer, if a thread exits and our saved dlerror result came
from that thread, the saved pointer could then refer to invalid memory.
The proper way to fix this is to use TLS and have a per-thread pointer
for __wrap_dlerror. However, instead of using up a TLS slot, this patch
keeps the single pointer for custom messages, and fallback to per-thread
dlerror call for system messages. While the race condition still exists,
I think the risk is acceptable. Even when races occur, they should no
longer cause crashes.
MozReview-Commit-ID: 4hGksidjiVz
--HG--
extra : rebase_source : 373000686c426b81ffd7cee88264e89b7a733957
There is no meaningful equality relationship on any plausible mutex
implementation other than object identity. Having MutexImpl's users simply
compare by addresses makes it clearer in the callers that that's what's going
on.
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : intermediate-source : ff41551f5ff1b98b72ed771a6f2a3f66a8b79a57
extra : absorb_source : c9fe7423fcbb47655b05209b44fb02b69b272d07
extra : source : 4b7a8a35ed956159e2f443c6211164c0cbf3d926
extra : histedit_source : b98b792791274f00a5e649c82dc25043cc1d699a
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : source : 4b7a8a35ed956159e2f443c6211164c0cbf3d926
extra : histedit_source : 01a1160ce1107d12e8b376d4512dedb0478e447c
Adding or removing an FD from this API currently requires changes in about a
half dozen places. Ignoring the Java side of things. This patch changes the
API to pass a struct, rather than additional arguments for each FD, so that
adding and removing FDs only requires changing one declaration, and the two
call sites that add and consume the FDs.
MozReview-Commit-ID: CToSEVp1oqP
--HG--
extra : rebase_source : 28e8c6075bacf5f610058227a9731aeadb50f320
extra : absorb_source : f63602a163ed19fb65e26640319750fdd9b92ad1
For clang-cl, we want to add code to libxul that only exists during the
PGO generation phase, so we can collect data. The most expedient way to
do that is to enable certain files in SOURCES to be marked as to only be
compiled during the PGO generation step.
In addition to updating the interface, this patch also significantly alters the
structure of this test. In particular, it removes the Test* functions in favour
of using template magic.
I did this because I noticed that, in the majority of cases, the stub function
was being called with all zero arguments, and then we check for the expected
error code. I thought that maybe we could replace that repetition with some
templates that instantiate a blank tuple that may then be applied to a callable
object.
See the (MAYBE_)TEST_HOOK* and TEST_DETOUR* macro definitions for detailed
information about how to use these things.
The test successfully completes with both 32-bit and 64-bit builds.
This patch makes the interceptor's AddHook functions private, and converts
the stubs from simple function pointers into objects containing both the stub
function pointer, plus a INIT_ONCE sentinel.
Setting a hook now requires calling Set or SetDetour on the stub, which ensures
that the hook attempt happens once and only once.
The constructor for the new object is constexpr, so it should not generate
static initializers if it is declared statically.
Note that, as a corollary of the new behaviour, we no longer need to set guards
around any hook setting code. I have removed those when present.
In addition to updating the interface, this patch also significantly alters the
structure of this test. In particular, it removes the Test* functions in favour
of using template magic.
I did this because I noticed that, in the majority of cases, the stub function
was being called with all zero arguments, and then we check for the expected
error code. I thought that maybe we could replace that repetition with some
templates that instantiate a blank tuple that may then be applied to a callable
object.
See the (MAYBE_)TEST_HOOK* and TEST_DETOUR* macro definitions for detailed
information about how to use these things.
The test successfully completes with both 32-bit and 64-bit builds.
This patch makes the interceptor's AddHook functions private, and converts
the stubs from simple function pointers into objects containing both the stub
function pointer, plus a INIT_ONCE sentinel.
Setting a hook now requires calling Set or SetDetour on the stub, which ensures
that the hook attempt happens once and only once.
The constructor for the new object is constexpr, so it should not generate
static initializers if it is declared statically.
Note that, as a corollary of the new behaviour, we no longer need to set guards
around any hook setting code. I have removed those when present.
In addition to updating the interface, this patch also significantly alters the
structure of this test. In particular, it removes the Test* functions in favour
of using template magic.
I did this because I noticed that, in the majority of cases, the stub function
was being called with all zero arguments, and then we check for the expected
error code. I thought that maybe we could replace that repetition with some
templates that instantiate a blank tuple that may then be applied to a callable
object.
See the (MAYBE_)TEST_HOOK* and TEST_DETOUR* macro definitions for detailed
information about how to use these things.
The test successfully completes with both 32-bit and 64-bit builds.
--HG--
extra : rebase_source : 95e9a3386c0a6c5f9f78b1e8fa5a88c1c30e9b51
This patch makes the interceptor's AddHook functions private, and converts
the stubs from simple function pointers into objects containing both the stub
function pointer, plus a INIT_ONCE sentinel.
Setting a hook now requires calling Set or SetDetour on the stub, which ensures
that the hook attempt happens once and only once.
The constructor for the new object is constexpr, so it should not generate
static initializers if it is declared statically.
Note that, as a corollary of the new behaviour, we no longer need to set guards
around any hook setting code. I have removed those when present.
--HG--
extra : rebase_source : 260ec9f99839468d9994186fddd7cf2b33e6c87d
clang-cl complains about things like:
z:/build/build/src/obj-firefox/dist/include/mozilla/interceptor/VMSharingPolicies.h(53,50): warning: use of identifier 'GetLocalView' found via unqualified lookup into dependent bases of class templates is a Microsoft extension [-Wmicrosoft-template]
return TrampolineCollection<MMPolicy>(*this, GetLocalView(), GetRemoteView(),
^
in various files in interceptor/, and since the warnings are in headers,
rather than in sources, they're rather annoying. Let's fix this to be
standards-complaint and make clang-cl stop complaining.
Csoregi Natalia
David Major
Jim Chen
Christian Holler
Narcis Beleuzu
Nathan Froyd
Aaron Klotz
Brian Hackett
Carl Corcoran
Jim Blandy
Kris Maglione
Brindusan Cristian
Chris Manchester
Ciure Andrei
Nathan Froyd
Gabriele Svelto
shindli
Coroiu Cristina
Margareta Eliza Balazs