[fpc-pascal] DLL calling Firebird 2: crashes at the end

[Reinier Olislagers]

On 28/09/2014 13:02, Mark Morgan Lloyd wrote:
> So in your case (2) there are three separate binaries which potentially
> allocate and free memory: (i) the database library (ii) the custom
> DLL/so and (iii) the application program, and in the general case each
> one should free precisely those areas of memory that it allocated: not a
> block more and preferably not a block less.
Yes, that sounds like how it should work/what I understand as well.

> Now if we assume that the database library has its own competent memory
> manager, and that its callers correctly tell it to free memory as soon
> as they're done with it (e.g. once a resultset has been parsed); that
> leaves potential problems in the custom library and application code.
Agreed.

> If the custom library never made any attempt to access Pascal-type
> (long) strings, dynamic arrays, or anything else on the heap which might
> be reallocated or extended when referenced (i.e. not just at creation),
> then you'd not need to do anything special. But as soon as the custom
> library tries to e.g. change the length of a string or dynamic array it
> makes a call to the memory manager, and if it's not sharing the same
> memory manager as the main app used to allocate the string/array that's
> a recipe for disaster.
Yes. 3 things:
1. I hopefully fixed memory allocation issues between application<>my
dll in the previous thread. Of course if you mean my dll modifying
strings etc in the firebird .so/.dll yes of course but why don't these
problems then occur with the simpler application<>Firebird .dll/.so?
2. Corruption does not occur when I compile my dll with database layer
code that does not call the Firebird sqldb layer i.e. the Firebird .so/.dll
3. I've tried both with and without cmem in both application and my dll
so they are definitely sharing the same memory manager. What the fb .so
uses... well... who knows, probably libc?!?!

> Now it might, potentially, be possible to tell a DLL/so as it is being
> loaded to link itself to the heap manager built into the main app. But
> the current preferred way is for the library and the app to use the same
> external memory manager, which is where importing cmem comes in.
> 
> So if you're getting crashes and your parameters are right, the first
> thing to check is that your custom library and the main app are both
> importing and using cmem before anything else such as HeapTrc. My
> experience is that that works, and if it isn't working then time you put
> into fixing it will probably be a useful investment.
Yes, see above.

> Here endeth the lesson. Go in peace.
Et lectori salutem & the same to you :)