[Gdal-dev] Re: Memory leak under Matlab (a follow up from - importFromWkt() problem)

[Frank Warmerdam]

Joaquim Luis wrote:
> Mateusz,
>> Sounds strange. Is there any chance you're misusing MEX memory
>> management functions or may be you're following one of MATLAB
>> buggy examples, like:
>> http://www.mathworks.com/support/solutions/data/1-1NOXOX.html
>>
>> May be you're using mexMakeMemoryPersistent in loop or similar call,
>> so memory is not cleared after your MEX is unloaded.
>> Note, it's only my surmise.
>>   
> 
> No, that should not be the problem.
> 
>> Are you using MATLAB on Windows?
>>   
> Yes.
>> Have you tried to run your MEX with a memory leak checker attached?
>> If you're using MATLAB on Windows, I'd try to build MEX dll with
>> VLD leak detector [1] but I'm not sure if it will give you usable
>> and meaningful report when working with MATLAB.
>>
>> [1] http://www.codeproject.com/tools/visualleakdetector.asp
>>   
> 
> OK, I'll see if that is possible.
> 
>> Another option is to do some simple  tests of memory
>> allocation/deallocation and observe how MATLAB will behave.
>>   
> 
> I tried that and never found a case with a memory leak. All cases that I 
> found
> occur when 3rth party libraries are used by the ML mexs (eg. gdal, gmt & 
> opencv).
> That is why I anticipate that the Mathworks support will be difficult to 
> convince,
> and that is also why that I'm trying to build the strongest as possible 
> case (or find out
> what is going on) before contacting them.
> 
> For example the following very short peace of code already produces the 
> memory
> leak, but in order to see (in the Windows Task Manager) it I have to run 
> the code many times.
> Something like:
> 
> for(i=1:5000);t=test_leak('+proj=longlat');end
> 
> However, in the original code from where this excerpt comes, the leak 
> was sufficiently  large
> to be seen only after a couple of executions.
> 
> Is there anyone who could test this on a system other than Windows?

Joaquim,

I'm not sure why you are running into a memory leak.  There are many variables
at play of course.  I tried a simple variation on your code and ran it under
valgrind which showed no related memory leaks.

#include "gdal.h"
#include "ogr_spatialref.h"


int main()

{
    char    *pszSrcSRS = NULL, *pszSrcWKT = NULL;
    char    *pszDstSRS = NULL, *pszDstWKT = NULL;
    OGRSpatialReference oSrcSRS, oDstSRS;

    pszSrcSRS = "WGS84";

    if( oSrcSRS.SetFromUserInput( pszSrcSRS ) != OGRERR_NONE )
        printf("OGRPROJ: Translating SRS string failed.\n");

    oSrcSRS.exportToPrettyWkt( &pszSrcWKT, FALSE );

    printf("%s\n",pszSrcWKT);

    OGRFree(pszSrcWKT);
}

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org