Since higher-level APIs that we test may depend on lower-level APIs that we
also test, and since those higher-level APIs may spin up background threads
that call those lower-level APIs, we should ensure that tests are ordered
such that the lower-level APIs are hooked first, thus preventing races where
higher-level background threads call lower-level APIs while the test's main
thread is in the midst of hooking a lower-level API.
I also added some fflush calls to the test so that, the next time we see lots
of crashes in this test, the log output is more complete.
Differential Revision: https://phabricator.services.mozilla.com/D37497
--HG--
extra : moz-landing-system : lando
Update the tests for ARM64 to include additional functions that are now
supported via 4 byte patching.
We also convert the TEST macros to accept the DLL names as strings, as this
works better with clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D32209
--HG--
extra : moz-landing-system : lando
In part 1, we disabled the unhooking of DLL-intercepted functions at shutdown. The TestDllInterceptor relied on unhooking -- it worked by hooking functions with a "nonsense function" (nullptr) and then immediately unhooking it. That restored the original function behavior. Some hooked functions (e.g. NtWriteFile) are used by functions later in the program (e.g. printf) so the functions need to maintain their behavior.
This patch replaces the nonsense function with an identity function that also sets a global boolean as a side-effect. The function is written in machine code. x86-32, x86-64, and aarch64 variants are included.
Differential Revision: https://phabricator.services.mozilla.com/D30244
--HG--
extra : moz-landing-system : lando
QueryCredentialsAttributesA and FreeCredentialsHandle trigger an exception when null is passed for the CredHandle pointer. This exception was ignored (when not run in the debugger) but that is no longer the case with the changes in part 3. This patch passes a real CredHandle to them.
Differential Revision: https://phabricator.services.mozilla.com/D30243
--HG--
extra : moz-landing-system : lando
Added a test to TestCrossProcessInterceptor that forcibly uses a 10-byte patch
on NtMapViewOfSection (which is a realistic case) and then ensures that
disabling the hook also works.
Differential Revision: https://phabricator.services.mozilla.com/D10286
--HG--
extra : moz-landing-system : lando
Added a test to TestCrossProcessInterceptor that forcibly uses a 10-byte patch
on NtMapViewOfSection (which is a realistic case) and then ensures that
disabling the hook also works.
Differential Revision: https://phabricator.services.mozilla.com/D10286
--HG--
extra : moz-landing-system : lando
Added a test to TestCrossProcessInterceptor that forcibly uses a 10-byte patch
on NtMapViewOfSection (which is a realistic case) and then ensures that
disabling the hook also works.
Differential Revision: https://phabricator.services.mozilla.com/D10286
--HG--
extra : moz-landing-system : lando
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.
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.
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
Aaron Klotz
Sylvestre Ledru
arthur.iakab
David Parks
Masatoshi Kimura
Bogdan Tara
Andreea Pavel
Tom Ritter
Ciure Andrei
Gabriele Svelto
shindli
David Major