diff options
author | Richard Levitte <levitte@openssl.org> | 2019-02-21 18:25:50 +0100 |
---|---|---|
committer | Richard Levitte <levitte@openssl.org> | 2019-02-22 21:04:47 +0100 |
commit | 4af54c9b9933336d1c48f3012aca92262c36d3a8 (patch) | |
tree | 26214e0b669bdb19525e10375edeef1d0361fc74 /ms/uplink.c | |
parent | f6d64b5142ab59be47c1f10512ce6d58fb399131 (diff) |
Windows: Call TerminateProcess, not ExitProcess
Ty Baen-Price explains:
> Problem and Resolution:
> The following lines of code make use of the Microsoft API ExitProcess:
>
> ```
> Apps\Speed.c line 335: ExitProcess(ret);
> Ms\uplink.c line 22: ExitProcess(1);
> ```
>
> These function calls are made after fatal errors are detected and
> program termination is desired. ExitProcess(), however causes
> _orderly_ shutdown of a process and all its threads, i.e. it unloads
> all dlls and runs all destructors. See MSDN for details of exactly
> what happens
> (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx).
> The MSDN page states that ExitProcess should never be called unless
> it is _known to be safe_ to call it. These calls should simply be
> replaced with calls to TerminateProcess(), which is what should be
> called for _disorderly_ shutdown.
>
> An example of usage:
>
> ```
> TerminateProcess(GetCurrentProcess(), exitcode);
> ```
>
> Effect of Problem:
> Because of a compilation error (wrong c++ runtime), my program
> executed the uplink.c ExitProcess() call. This caused the single
> OpenSSL thread to start executing the destructors of all my dlls,
> and their objects. Unfortunately, about 30 other threads were
> happily using those objects at that time, eventually causing a
> 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the
> best case scenario, as I'm sure you can imagine at the consequences
> of undiscovered memory corruption, even in a terminating process.
And on the subject of `TerminateProcess()` being asynchronous:
> That is technically true, but I think it's probably synchronous
> "enough" for your purposes, since a call to TerminateProcess
> suspends execution of all threads in the target process. This means
> it's really only asynchronous if you're calling TerminateProcess one
> some _other_ process. If you're calling TerminateProcess on your own
> process, you'll never return from the TerminateProcess call.
Fixes #2489
Was originally RT-4526
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8301)
(cherry picked from commit 925795995018bddb053e863db8b5c52d2a9005d9)
Diffstat (limited to 'ms/uplink.c')
-rw-r--r-- | ms/uplink.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/ms/uplink.c b/ms/uplink.c index 7f7abfbe57..2096f2cacf 100644 --- a/ms/uplink.c +++ b/ms/uplink.c @@ -28,7 +28,7 @@ static TCHAR msg[128]; static void unimplemented(void) { OPENSSL_showfatal(sizeof(TCHAR) == sizeof(char) ? "%s\n" : "%S\n", msg); - ExitProcess(1); + TerminateProcess(GetCurrentProcess(), 1); } void OPENSSL_Uplink(volatile void **table, int index) |