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

[Mark Morgan Lloyd]

Reinier Olislagers wrote:

>> 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?

But when your code modifies strings in the context of the database 
library they're preallocated C-type strings, i.e. can't be extended or 
shrunk so don't make unexpected reference to any memory manager.

> 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

Interesting. So if I understand you correctly it's only when you've got 
two levels of dynamically-loaded library, i.e. one DLL is responsible 
for loading another.

Now would probably be a good time to try Postgres as an alternative.

> 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?!?!

Probably libc, but not really relevant since all the allocate/free 
operations are done in the same context: the lib giveth, and the lib 
taketh away :-)

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]