summaryrefslogtreecommitdiff
path: root/filter
diff options
context:
space:
mode:
authorChris Sherlock <chris.sherlock79@gmail.com>2017-03-11 14:03:38 +1100
committerChris Sherlock <chris.sherlock79@gmail.com>2017-03-15 07:11:05 +0000
commit7fafd1aea08ad036ef48f415db5df93df218bf6e (patch)
tree1651e1af5159ae8af0d63c1ec0db67f73d475a52 /filter
parent2589f090875f3b81d91211e72cf36a6f1441c01a (diff)
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 'filter')
0 files changed, 0 insertions, 0 deletions