[Lazarus] Buffer dealocating between program and C++ library

[Leonardo M. Ramé]

On 2011-05-12 00:36:34 +0200, Mattias Gaertner wrote:
> On Wed, 11 May 2011 15:35:40 -0300
> Leonardo M. Ramé <l.rame at griensu.com> wrote:
> 
> > Hi, I'm using a C++ library created by me, with a function that let me get an image buffer. 
> > I use that buffer to do some processing, then I can tell the library to delete the buffer.
> > 
> > In Linux, I never had an issue between my Lazarus program and that
> > library, but yesterday I decided to port it to Windows, and found the
> > buffer is never deleted, causing a "Microsoft Visual C++ Runtime
> > library, runtime error....". The library is compiled with Mingw32.
> > 
> > After having found the error, I created a C++ program that calls the
> > problematic method 1000 times, and noted the memory is handled
> > correctly, then I made a simple FPC program that does the same thing,
> > and found the same behavior as in Lazarus.
> > 
> > Here are the signatures for the functions exported by the library:
> > 
> >   TgetDicomImage = function(const ADicomImage: Pointer; out buffer: Pointer;
> >     out bufSize: longint; ALeft, ATop: double; var AWidth, AHeight: double): integer; cdecl;
> > 
> >   TdeleteBuffer = procedure(ABuffer: PByte); cdecl;
> > 
> > 
> > And here is a snippet of the code I use to test the function:
> > 
> > 
> >   Pointer(lGetDicomImage) := GetProcAddress(lLibHandle, 'getDicomImageBufferEx');
> >   Pointer(lDeleteBuffer) := GetProcAddress(lLibHandle, 'deleteBuffer');
> > 
> >   for I := 0 to 1000 do
> >   begin
> >     if @lGetDicomImage <> nil then
> 
> if lGetDicomImage <> nil then
> 
> What mode are you using? Delphi?

No, I'm using objfpc. 

 > 
> >         if @lDeleteBuffer <> nil then
> >           lDeleteBuffer(lBuffer); // <----- memory keeps increasing here.
> >       end;
> 
> end;
> if lBuffer<>nil then
>   lDeleteBuffer(lBuffer);

I don't understand this. Do you mean, I should call lDeleteBuffer aftert
the "end;" that closes the loop?.

-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com