| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
| |
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7769)
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 9c1a9ccf65d0ea1912675d3a622fa8e51b524b9e.
TerminateProcess is asynchronous, so the code as written in the above
commit is not correct. It is also probably not needed in the speed
case. Reverting in order to figure out the correct solution.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
|
|
|
|
|
| |
Add copyright to missing assembler files.
Add copyrights to missing test/* files.
Add copyrights
Various source and misc files.
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
| |
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
| | |
|
| |
|
|
| |
PR: 1382
|
| | |
|
|
|
make it possible to produce for a unified binary build, which can be
used with a variety of Win32 compilers.
|
