diff options
author | Chris Sherlock <chris.sherlock79@gmail.com> | 2017-03-11 14:03:38 +1100 |
---|---|---|
committer | Chris Sherlock <chris.sherlock79@gmail.com> | 2017-03-15 07:11:05 +0000 |
commit | 7fafd1aea08ad036ef48f415db5df93df218bf6e (patch) | |
tree | 1651e1af5159ae8af0d63c1ec0db67f73d475a52 /editeng/source/items | |
parent | remove unused HRC defines in sd/ (diff) | |
download | core-7fafd1aea08ad036ef48f415db5df93df218bf6e.tar.gz core-7fafd1aea08ad036ef48f415db5df93df218bf6e.zip |
tdf#106489 - Win32 version of osl_terminateProcess not "safe"
The current Win32 implementation of osl_terminateProcess calls directly
upon the Win32 TerminateProcess() API function. When I looked up this
function on MSDN I was a bit surprised to note that this is an
asynchronous function that returns immediately before the process
actually fully terminates, and does not necessarily succeed cleanly.
As we are not checking that the process actually fully terminates,
this is a bit of a problem, albeit one I think may well be somewhat
obscure and non-obvious. In fact, it is better that we call on
TerminateProcess() and use WaitForSingleObject() until the process
actually fully terminates. If the termination ends abnormally, then we
should pass a more appropriate exit status.
Dr Dobbs magazine, bless its ancient archive, details a "safe" version
of TerminateProcess(), which has been implemented it seems in dozens of
projects already so it's basically at this point a pattern. The article
can be found here:
http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547
Thankfully, the flaws they point out are only valid due to the age of
the article as the Windows 9x line of operating systems was still a
thing way back then :-)
Changes that are made:
1. If the PID is 0x0 then this can't be ended, so return an invalid
status
2. We need to elevate access to the process handle to allow it to
create a new thread in a potentially remote process, so we use
DuplicateHandle to do so
3. The core change is to change from TerminateProcess() to
ExitProcess(), I'm letting it timeout forever and the end user can
kill off the process via a Windows process management tool if
they need it killed entirely, hence WaitForSingleObject() has an
infinite timeout.
This way, the termination handler is now called and the attached
dlls are notified that they are being detached from the process.
Change-Id: Icfa7c60c35a088b8f9834351bc7953a910247fb8
Reviewed-on: https://gerrit.libreoffice.org/35071
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Diffstat (limited to 'editeng/source/items')
0 files changed, 0 insertions, 0 deletions