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

[Mark Morgan Lloyd]

Reinier Olislagers wrote:
> On 29/09/2014 17:41, Mark Morgan Lloyd wrote:
>> Reinier Olislagers wrote:
>>> On 29/09/2014 11:19, Mark Morgan Lloyd wrote:
>>>> Reinier Olislagers wrote:
>>>>> 2. In businesslayer.pas, $define CRASH to see the problem.
>>>>> The code in question is:
>>>>> initialization
>>>>>   DBLayer:=TDBInterface.Create;
>>>>>
>>>>> finalization
>>>>>   DBLayer.Free;
>>>>> ... so probably initialization order plays a part?!?
>>>>>
>>>>> How should I fix this?
>>>> What happens if you move the responsibility for initialising and closing
>>>> the database connection to the app-level code? In other words, the app
>>>> does something like
>>> As the demo indicates, that does work (undefine CRASH).
>>>
>>> What I would like to know what is the cause of this problem - dlls being
>>> loaded before some kind - what kind? - of initialization is complete?
>>>
>>> Anyway, I'll keep digging; probably first looking at geting postgresql
>>> support in anyway.
>> No, your example shows an implicit initialisation when the backend is
>> accessed.
> Agreed... but as that code works there's no reason to suspect your
> approach won't work & my finished program sucesfully uses your approach ;)
> 
> Re bug report: agreed. I'll raise it.

Jose's comment about not (in effect) putting TIBConnection.Create() in 
the initialisation block of a program (hence of a DLL or .so) is 
interesting. Assuming that he is correct I think it's worth wondering 
/why/ he's correct, and if that is in fact a symptom of something wrong 
with the FPC initialisation sequence.

If he's correct, I'd expect the problem to persist even if your 
businesslayer DLL were loaded on-demand rather than at the whim of the 
OS: the binary state of the DLL/so in memory would be inappropriate for 
reliable operation.

If you still have problems when you call TIBConnection.Create() after 
all initialisation is complete, then you need to consider whether any 
state in the DLL/so has to be transferred to the main program. Hopefully 
you don't need to get involved with that.

A final thing to consider is that if there is an asynchronous element in 
database initialisation it could end up being difficult for the main 
program to check that the DLL/so was ready to use.

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

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