Reproducible code: DLL calling Firebird crashes

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Reproducible code: DLL calling Firebird crashes

Sven Barth-2

Am 30.09.2014 22:19 schrieb "Mark Morgan Lloyd" <[hidden email]>:
>
> Sven Barth wrote:
>
>> The only other alternative would be to add the RTL initialization code to each exported function. I don't consider this a viable alternative.
>
>
> Which is more or less what Reinier's working code did. I'd hate that to be an implicit default.
>
>
>> Note: Dynamic packages won't have this problem, because:
>> - for packages linked at compile time the initialization is run as part of the program initialization AFTER the OS has initialized the library (which doesn't do much in case of a package)
>> - for packages loaded at runtime it's done as part of the LoadPackage call
>> That's however only possible, because dynamic packages are very different from simple libraries (and stuffed with compiler magic).
>
>
> Is it possible for code in a unit to determine what sort of project it's part of, i.e. a standalone program, a library etc.? Could the RTL have a flag indicating that initialisation (or finalisation?) blocks were currently being run, and anything called should assume that facilities were restricted?

Isn't there a IsLibrary variable in System? For sure there is a IsPackage variable which will be true if the unit is part of a package (though I still need to find out how to implement this).
You don't need a flag for initialization/finalization blocks, because if your code resides in one then you are obviously run inside one...

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Reproducible code: DLL calling Firebird crashes

Reinier Olislagers
In reply to this post by Mark Morgan Lloyd-5
On 30/09/2014 22:05, Mark Morgan Lloyd wrote:
> Marco van de Voort wrote:
>> In our previous episode, Sven Barth said:
>>> It is indeed true that all units are initialized once the main code
> Reinier: did you get as far as looking in Dynlibs for an error message
> immediately after trying to connect to the database?

No, I didn't.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Reproducible code: DLL calling Firebird crashes

Marco van de Voort
In reply to this post by Sven Barth-2
In our previous episode, Sven Barth said:
> > So the obvious question might be if the unit initialization really  belongs
> > into the library initialization like that.
>
> The only other alternative would be to add the RTL initialization code
> to each exported function. I don't consider this a viable alternative.

Simpler, for manual managed DLLs, you need to manually call an initialization and
finalization. Period.
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Reproducible code: DLL calling Firebird crashes

Mark Morgan Lloyd-5
In reply to this post by Reinier Olislagers
Reinier Olislagers wrote:
> On 30/09/2014 22:05, Mark Morgan Lloyd wrote:
>> Marco van de Voort wrote:
>>> In our previous episode, Sven Barth said:
>>>> It is indeed true that all units are initialized once the main code
>> Reinier: did you get as far as looking in Dynlibs for an error message
>> immediately after trying to connect to the database?
>
> No, I didn't.

Assuming you've got >= 2.6.2, modify your code to look like this:

uses DynLibs;
..
   WriteLn('Before TDBInterface.Create(): ', GetLoadErrorStr);
   DBLayer:=TDBInterface.Create;
   WriteLn('After TDBInterface.Create(): ', GetLoadErrorStr);

On Linux, I can see it calling the database connection stuff but then it
raises an exception because it can't find the named server etc. So at
least on Linux it's apparently transferring control into the
demand-loaded database stuff, since otherwise there wouldn't be the
messages as shown below. Whether it's appropriate and portable to do it
like that is a different issue.

I don't want to have to spend time changing your test code to suit
PostgreSQL or digging out names etc. for the limited number of Firebird
databases I've got set up, and I /really/ don't want to start fiddling
with Windows.

Before TDBInterface.Create():
An unhandled exception occurred at $B767EFEF :
EIBDatabaseError :  : DoInternalConnect :
  -Unable to complete network request to host "firebirdserver".
  -Failed to locate host machine.

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

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Reproducible code: DLL calling Firebird crashes

Reinier Olislagers
On 02/10/2014 12:19, Mark Morgan Lloyd wrote:

> Reinier Olislagers wrote:
>> On 30/09/2014 22:05, Mark Morgan Lloyd wrote:
>>> Marco van de Voort wrote:
>>>> In our previous episode, Sven Barth said:
>>>>> It is indeed true that all units are initialized once the main code
>>> Reinier: did you get as far as looking in Dynlibs for an error message
>>> immediately after trying to connect to the database?
>>
>> No, I didn't.
>
> Assuming you've got >= 2.6.2, modify your code to look like this:

Sorry to be a bit abrupt here but I'm not really interested in tweaking
this either. I've submitted a bug report which was closed. If anybody
else wants to look into this, fine by me, but I won't spend any more
time on it.

Some background: if I'm using e.g. FPC-provided units that just happen
to load dlls dynamically (such as sqldb but probably also others) I, as
a programmer, do not necessarily know or want to know that
implementation detail. Rather than messing with havint to adapt code for
those scenarios I'll just not use the initalization sections at all as I
documented on the wiki.

Thanks for all the help.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Reproducible code: DLL calling Firebird crashes

Michael Van Canneyt


On Thu, 2 Oct 2014, Reinier Olislagers wrote:

> On 02/10/2014 12:19, Mark Morgan Lloyd wrote:
>> Reinier Olislagers wrote:
>>> On 30/09/2014 22:05, Mark Morgan Lloyd wrote:
>>>> Marco van de Voort wrote:
>>>>> In our previous episode, Sven Barth said:
>>>>>> It is indeed true that all units are initialized once the main code
>>>> Reinier: did you get as far as looking in Dynlibs for an error message
>>>> immediately after trying to connect to the database?
>>>
>>> No, I didn't.
>>
>> Assuming you've got >= 2.6.2, modify your code to look like this:
>
> Sorry to be a bit abrupt here but I'm not really interested in tweaking
> this either. I've submitted a bug report which was closed. If anybody
> else wants to look into this, fine by me, but I won't spend any more
> time on it.
>
> Some background: if I'm using e.g. FPC-provided units that just happen
> to load dlls dynamically (such as sqldb but probably also others) I, as
> a programmer, do not necessarily know or want to know that
> implementation detail. Rather than messing with havint to adapt code for
> those scenarios I'll just not use the initalization sections at all as I
> documented on the wiki.

That is my conclusion since ages: I don't use initialization sections,
except maybe to initialize a variable.

You quickly learn this when you need to debug e.g. windows services.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12