[gdal-dev] Kernel resource leak -- Windows

[Joaquim Luis]

On 01-10-2013 20:08, Even Rouault wrote:
> Le lundi 30 septembre 2013 00:59:33, Joaquim Luis a écrit :
>> Hi,
>>
>> I can make a ticket with this but before, let me just report it here.
>>
>> - Win 64 bits GDAL build
>>
>> While playing with an Intel analysis tool to chase GMT memory leaks I
>> got two complains respecting GDAL.
>>
>> P1: Error: Kernel resource leak
>>    P1.55: Kernel resource leak: New
>>     c:\programs\gdaltrunk\gdal\port\cpl_multiproc.cpp(626): Error X63:
>> Critical section creation site: Function CPLCreateMutex: Module
>> C:\progs_cygw\GMTdev\gmt5\trunk\WIN64\bin\gdal_w64.dll
>>     Code snippet:
>>      624      if( pcs )
>>      625      {
>>
>>   >626        InitializeCriticalSectionAndSpinCount(pcs, 4000);
>>
>>      627        EnterCriticalSection(pcs);
>>      628      }
>>
>> The MS Help says that this can be solved with a call
>> to'FindCloseChangeNotification'
> MSDN doesn't mention FindCloseChangeNotification as a valid function to call
> related to the use of InitializeCriticalSectionAndSpinCount.
>
> Is it really a repeated memory leak (something that will be leaked each time
> you call CPLCreateMutex() - with correctly paired CPLDestroyMutex() - and that
> will end up exhausting memory / kernel ressources ) or just a one time memory
> leak (something that a tool like valgrind would report as 'still reachable' at
> the end of the process) due to one of the main "static" GDAL mutex not being
> freed ?
>

I don't think it is a memory leak but it's the first time I see this. 
The description I get from something called "Microsoft Help Viewer 1.1 
'' Catalog VS_100_EN-US" is:

"Kernel Resource Leak
Occurs when a kernel object handle is created but never closed"

and it has a table with possible solutions to solve the leak. First 
column says "Create Function" and second "Close function"

InitializeCriticalSection, InitializeCriticalSectionAndSpinCount

	

DeleteCriticalSection


Sorry if I can't be more useful but as i said this is completely new to me.

Joaquim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20131002/03d5c929/attachment.html>