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

[Michael Van Canneyt]

On Tue, 30 Sep 2014, Mark Morgan Lloyd wrote:

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

The memory manager problem is completely unrelated to this. 
DLL and calling program simply have different copies of the FPC memory manager.
That is what needs to be solved with dynamic packages.

As far as I know, the initialization entry point is called automatically.
But the compiler experts should confirm this. IIRC the behaviour changed 
as the support for libraries improved;

Michael.