[fpc-pascal] DLL calling Firebird 2: crashes at the end
reinierolislagers at gmail.com
Sun Sep 28 11:51:06 CEST 2014
On 28/09/2014 11:30, Mark Morgan Lloyd wrote:
> Reinier Olislagers wrote:
> Can you link the lookup DLL/so statically for test purposes?
I'll have a look.
>> If I add cmem first in the .so uses clause, I get this on running my
>> dlldemo application:
>> Inconsistency detected by ld.so: dl-minimal.c: 136: realloc: Assertion
>> `ptr == alloc_last_block' failed!
> If adding cmem to one you might need it in both to be effective.
Ah yes. That does fix that ld error.
#0 0x00007ffff785be75 in fpc_ansistr_decr_ref ()
#1 0x00000000006c0ca0 in ?? ()
#2 0x00007ffff785bf05 in fpc_ansistr_assign ()
#3 0x00000000006add18 in U_$SYSTEM_$$_OUTPUT ()
#4 0x0000000000400ac0 in SetCity at plt ()
#5 0x00000000006add18 in U_$SYSTEM_$$_OUTPUT ()
#6 0x00007ffff78c3c8b in SETSTREET (this=0x6c0c78, AVALUE=0x0)
#7 0x00007ffff785178f in CLEARADDRESS () at dutchpostcode.lpr:91
#8 0x0000000000401118 in main () at dlldemo.lpr:116
> I presume that in your
> case you're leaving the OS to do the load when the program starts,
Yes, I am.
> but I
> think that the same points about memory managers etc. apply. I have used
> demand-loaded libraries to interface to e.g. custom processing for MIDI
> or to optionally load e.g. libpcap, and once working it's reliable.
May be me, but I have trouble understanding why:
1. A regular program loading Firebird .so/.dlls works without any
specified cmem etc. Here application<>Firebird dll
2. An FPC library, coded similarly to 1., fails.
Here application<>dll<>Firebir dll
The difference between the 2 seems to me application coupled directly to
FB dll versus coupling to FPC dll.
Why should that make a difference?
Why should I worry about memory managers etc in the second case but not
the first? (Assuming I did not create problems with application<>dll
More information about the fpc-pascal