__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.
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
When we modify the debug map, we could be racing with the system linker,
either when we modify the entries or when we change page protection
flags. To fix the race, we need to take the system linker's internal
lock when we perform any kind of modification on the debug map.
One way to hold the system linker lock is to call dl_iterate_phdr, and
perform our actions inside the callback, which is invoked with the
lock being held. However, dl_iterate_phdr is only present on Android
5.0+, and even then, dl_iterate_phdr is only protected by the linker
lock on Android 6.0+.
This means that with this patch, we can only safely modify the debug map
on Android 6.0+, which I think is acceptable for an operation that only
benefits a debugger.
MozReview-Commit-ID: BowBEO8tu8Z
--HG--
extra : amend_source : 837631dfc2ef17b24ffe5778bcb70dc29b7dfc66
* This allows us to use a single blocklist definition in multiple places.
* This patch also adds support for a new initialization flag that, when enabled,
disables the DLL Blocking part of the mozglue blocklist but leaves the
profiling and stackwalking suppression bits intact.
* This allows us to use a single blocklist definition in multiple places.
* This patch also adds support for a new initialization flag that, when enabled,
disables the DLL Blocking part of the mozglue blocklist but leaves the
profiling and stackwalking suppression bits intact.
--HG--
extra : rebase_source : ff4dad72f57c5662fc9e1bbd9e4efb3ff01470ef
GetThreadContext() returns a context pointing to its own frame when it
gets called with the current thread handle. That frame can go away after
it returns. This patch instead uses RtlCaptureContext(), which captures
the context of its caller, when walking the current thread.
In the past, we also used a walker thread when nullptr is passed in for
aThread, but the check doesn't cover all the cases, and having another
thread is apparently more complicated than this approach.
MozReview-Commit-ID: 3TAatDc9BLh
--HG--
extra : rebase_source : 7978cce48b8939a723cd5ccafe86d3f7aca6d3ac
GetCurrentThread() returns a pseudo handle, so comparing it against
the passed in argument doesn't make sense in most cases. This patch
changes it to using the thread id for comparison, which is guaranteed
to be unique in the whole lifetime of a thread.
MozReview-Commit-ID: 5TNAgLkcS6m
--HG--
extra : rebase_source : d5bb21ac57a4c1149b8d332ea7b28a78ed994c62
GetThreadContext() returns a context pointing to its own frame when it
gets called with the current thread handle. That frame can go away after
it returns. This patch instead uses RtlCaptureContext(), which captures
the context of its caller, when walking the current thread.
MozReview-Commit-ID: 3TAatDc9BLh
--HG--
extra : rebase_source : d5d88f0a9fa07da5b31f27c51c78ee2bfb527a8e
GetCurrentThread() returns a pseudo handle, so comparing it against
the passed in argument doesn't make sense in most cases. This patch
changes it to using the thread id for comparison, which is guaranteed
to be unique in the whole lifetime of a thread.
MozReview-Commit-ID: 5TNAgLkcS6m
--HG--
extra : rebase_source : 0e72e8f6196c8079086ca697b9a121c6987ef43e
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
We are apparently still crashing even after mprotect() with write flag
returns successfully. This patch reads the flags again after mprotect()
returns, and hopefully the flags will tell the truth of whether the page
is truly writable or not after calling mprotect().
MozReview-Commit-ID: Jsg8vHKFEvJ
--HG--
extra : rebase_source : b028aa0d5cefd50302bfc2502292d9129d202e09
This also changes many references to the 'pseudo stack' to refer to the 'label
stack' instead. The label stack is one of the two stacks that are managed by
the profiling stack, the other stack being the JS interpreter stack.
MozReview-Commit-ID: Ed0YMMeCBY8
--HG--
extra : rebase_source : 5675d670f424c7d7dda04bafc2b3431fa2485e3c
The term "entry" is already used for elements in the profile buffer.
MozReview-Commit-ID: 1aB22V6veQh
--HG--
extra : rebase_source : c664eb4d6bed6cb74ba8a1b67ea99bd8ca57bcf7
extra : source : 3264c0cc0027b240b55bd3aebf27263b1e1d1cc0
The name Cpp was confusing, because C++ functions are in the native stack, not
in the pseudo stack. The pseudo stack only contains frames for manually
instrumented code that uses AutoProfilerLabel, and JS frames.
MozReview-Commit-ID: 9ptfhREo0qy
--HG--
extra : rebase_source : 76a1a32acb4c946aeb2ad45e904e419c1c9e2ad1
It was necessary back when we were doing decompression from a signal
handler, because we couldn't then have zlib call malloc, but we don't
do that anymore, so the whole wrapping is effectively unused.
With the wrapping gone, we manually initialize the zalloc, zfree and
opaque fields, as specified in the zlib documentation.
--HG--
extra : rebase_source : c4e84009e65f71f6c43362468c2934e04a8abda1
Masatoshi Kimura
Tom Ritter
Cosmin Sabou
Changqing Li
Aaron Klotz
Csoregi Natalia
David Major
Jim Chen
Christian Holler
Narcis Beleuzu
Nathan Froyd
Brian Hackett
Carl Corcoran
Jim Blandy
Kris Maglione
Brindusan Cristian
Chris Manchester
Ciure Andrei
Nathan Froyd
Gabriele Svelto
shindli
Coroiu Cristina
Margareta Eliza Balazs
Andrew Halberstadt
Ryan VanderMeulen
Xidorn Quan
Sylvestre Ledru
Emilio Cobos Álvarez
Markus Stange
Eric Rahm
Mike Hommey
Jon Coppeard
Hiroyuki Ikezoe
arthur.iakab
Dorel Luca
James Willcox