[openssl] master update

[Richard Levitte]

The branch master has been updated
       via  925795995018bddb053e863db8b5c52d2a9005d9 (commit)
      from  3409a5ff8a44ddaf043d83ed22e657ae871be289 (commit)


- Log -----------------------------------------------------------------
commit 925795995018bddb053e863db8b5c52d2a9005d9
Author: Richard Levitte <levitte at openssl.org>
Date:   Thu Feb 21 18:25:50 2019 +0100

    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 at openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/8301)

-----------------------------------------------------------------------

Summary of changes:
 ms/uplink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ms/uplink.c b/ms/uplink.c
index 02d466f..8c61a7e 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)