[openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l

[Jakob Bohm]

Following up on this somewhat old thread just to correct some
misunderstandings about the nature of the Windows APIs.

On 25/01/2015 19:49, Michel SALES wrote:
> Hi Avery,
>
>> In the code I sent over before, I was calling CloseHandle on the thread:
>> HANDLE h1=CreateThread(0,0,thread1,0,0,&t1);  if(h1==0) { return
> 0; } CloseHandle(h1);
>
> Yes, but you were trying to close the handle of a thread which was still
> running !
> I have not checked what happens in this case.
Just FYI: On Windows (unlike the fork-like semantics of POSIX
pthreads), the handle to a thread is just one of N references
to the thread object, another of which is the actual fact of
the thread still running.  As long as at least one such
reference exists, the kernel resources associated with the
thread (an ETHREAD structure, the thread identifier etc.)
remain in use.  The act of waiting for and/or closing the
handle has no direct relationship to thread exit.  So closing
an unwanted thread handle right after thread creation is a
normal and correct resource saving coding technique.
> I am not sure to fully understand what your are doing now, but with the
> modified version I've sent to you, _CrtDumpMemoryLeaks() doesn't report any
> problem on my Windows 7 64 bits machine.
Note that _Crt functions only check internal state in the
per-compiler C runtime, they cannot check for leaks of OS
level objects, that requires OS tools, such as those
available via Task manager (taskmgr.exe) and the OS level
debuggers (WinDbg.exe, GFlags.exe etc.).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded