[fpc-pascal] Reproducible code: DLL calling Firebird crashes

[Mark Morgan Lloyd]

Michael Van Canneyt wrote:
> On Tue, 30 Sep 2014, Mark Morgan Lloyd wrote:
> 
>> Reinier Olislagers wrote:
>>> On 29/09/2014 19:30, Reinier Olislagers wrote:
>>>> Re bug report: agreed. I'll raise it.
>>
>> Jonas has already closed it, noting
>>
>> "http://msdn.microsoft.com/en-us/library/windows/desktop/ms682583%28v=vs.85%29.aspx 
>>
>>
>> "***
>> The entry-point function should perform only simple initialization or 
>> termination tasks. It must not call the LoadLibrary or LoadLibraryEx 
>> function (or a function that calls these functions), because this may 
>> create dependency loops in the DLL load order. This can result in a 
>> DLL being used before the system has executed its initialization code.
>> ***
>>
>> "I.e., what you are doing is unsupported ("must not call the 
>> LoadLibrary or LoadLibraryEx function"). I think that on most unix 
>> platforms, trying to load libraries from other the init function of 
>> other libraries is not supported either."
>>
>> However I'd precede that by a thought based on what Jose said. In your 
>> example, you're opening the database in the initialisation block of 
>> businesslayer.pas, which is invoked at an arbitrary position in the 
>> init sequence of the DLL/so. If that operation were moved instead to 
>> the initialisation block of testdbdll.lpr, which in the context of the 
>> DLL/so is analogous to a program's main block, it might work.
> 
> No. this is not correct. For a library, this is analogous to 
> initialization code of a unit, it's just the 'last' unit being initialized.

Does the main program explicitly call the initialisation entry point of 
the (dynamically-loaded) library, or it this done by the OS? I was under 
the impression that the two were basically asynchronous and (as a 
particular example) both the program and the library would have distinct 
copies of the system unit with their own global variables etc. hence the 
memory manager problem.

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

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