summaryrefslogtreecommitdiffstats
path: root/ms
diff options
context:
space:
mode:
authorRichard Levitte <levitte@openssl.org>2019-02-21 18:25:50 +0100
committerRichard Levitte <levitte@openssl.org>2019-02-22 21:04:47 +0100
commit4af54c9b9933336d1c48f3012aca92262c36d3a8 (patch)
tree26214e0b669bdb19525e10375edeef1d0361fc74 /ms
parentf6d64b5142ab59be47c1f10512ce6d58fb399131 (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')
-rw-r--r--ms/uplink.c2
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)