<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#333333">
I have a fairly simple Win32 application (.cpp file source code
attached) that uses OpenSSL 1.0.1l to send some GET requests in 2
threads. I am getting reports of Handle Leaks in C++ memory
validator (see logs at bottom of email), but I can't find what is
wrong with my code (if anything). The app appears to function
perfectly and the memory doesn't appear to rise in task manager..
but I'm still worried about the Handle Leak reports. <br>
<br>
* It should be noted that even if I get rid of the threads all
together and just call 2 functions for the GET requests, I still get
these same leak reports. So I don't think its a thread related
problem.<br>
<br>
Also, the reason I'm not using CRYPTO_set_locking_callback is
because I am already using WaitForSingleObject and ReleaseMutex to
make sure its impossible for two threads to be running at the same
time. Unless I'm missing something, CRYPTO_set_locking_callback is
not needed due to the way I coded this.<br>
<br>
Can someone please verify if the code is thread safe, and comment
regarding what might be causing these handle leaks? Maybe it is
nothing to be worried about -- not sure..<br>
<br>
Are there any other problems you see in the code? Perhaps missing
cleanup functions? Or is everything OK and I'm just over analyzing
this?<br>
<br>
Thanks for any tips!<br>
<br>
Best Regards,<br>
<br>
-Avery<br>
<br>
<br>
Address / Handle: 0x0000C001<br>
shmem-win32.c<br>
sslleak.exe <br>
Atom<br>
0 bytes<br>
Thread ID: 6736<br>
1/22 18:48:09 990ms (Lifetime:00:01:45:503ms)<br>
Sequence: 11<br>
sslleak.exe ___shmem_grab : [shmem-win32.c Line 0]<br>
sslleak.exe _fc_key_init_once : [unwind-sjlj.c Line 0]<br>
sslleak.exe _main : [crt0_c.c Line 0]<br>
sslleak.exe ___tmainCRTStartup : [crtexe.c Line 0]<br>
kernel32.dll BaseThreadInitThunk : [{FUNC}BaseThreadInitThunk Line
0]<br>
ntdll.dll RtlInitializeExceptionChain :
[{FUNC}RtlInitializeExceptionChain Line 0]<br>
<br>
<br>
<br>
Address / Handle: 0x0000C00F<br>
shmem-win32.c<br>
sslleak.exe <br>
Atom<br>
0 bytes<br>
Thread ID: 6736<br>
1/22 18:48:09 990ms (Lifetime:00:02:29:683ms)<br>
Sequence: 97<br>
sslleak.exe ___shmem_grab : [shmem-win32.c Line 0]<br>
sslleak.exe ___shmem_grab : [shmem-win32.c Line 0]<br>
<br>
<br>
Address / Handle: 0x0000C016<br>
shmem.c<br>
sslleak.exe <br>
Atom<br>
0 bytes<br>
Thread ID: 6736<br>
1/22 18:48:09 990ms (Lifetime:00:03:02:693ms)<br>
Sequence: 143<br>
sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0]<br>
sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0]<br>
sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0]<br>
sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0]<br>
sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0]<br>
sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0]<br>
<br>
<br>
Address / Handle: 0x0000C009<br>
shmem.c<br>
sslleak.exe <br>
Atom<br>
0 bytes<br>
Thread ID: 6736<br>
1/22 18:48:09 990ms (Lifetime:00:03:22:364ms)<br>
Sequence: 61<br>
sslleak.exe ___shmem_winpthreads_grab : [shmem.c Line 0]<br>
sslleak.exe _mutex_static_init : [mutex.c Line 0]<br>
sslleak.exe _pop_pthread_mem : [thread.c Line 0]<br>
sslleak.exe _pop_pthread_mem : [thread.c Line 0]<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>