Subject | Re: [firebird-support] Engine crash on gds_free |
---|---|
Author | Helen Borrie |
Post date | 2004-06-10T08:21:21Z |
Björn,
At 07:56 AM 10/06/2004 +0000, you wrote:
log in the normal course of events, i.e., something really unexpected is
happening and the engine is doing its best to provide some clues. Whatever
happens next to crash the engine one cannot see, of course, since a crashed
engine can't write log messages.
"real wire protocol" to connect, rather than "localhost" (IP address
127.0.0.1) that signals to the network layer that you are in local
loopback. This *could* have something to do with a difference in the
keepalive techniques used for node-to-node connections (your protocol) and
local loopback. A fix was done for the 1.5.1 point release to correct a
crashing problem in 1.5, and the two conditions might be related.
When you report to firebird-devel, mention whether you are using events in
your application. btw, if you are using IBO's DML Caching, then you *are*
using events, under the hood.
Also, do a double-check on the property sheet of gds32.dll to verify that
you have the correct client.
/heLen
At 07:56 AM 10/06/2004 +0000, you wrote:
>Hi,I recommend that you repeat this question in firebird-devel.
>as I could not get any answers sofar I need to ask again as I fear that
>this behaivour might corrupt databases.
>
>I recently experienced an engine crash with FB 1.0.3 on Win2000 Server.
>Clients developed with IBO 4.3Aa and Delphi7. Clients and Server run on a
>Dell 2 Processor Xeon Server with HT enabled. DB is fixed to use 1 CPU
>only via configuration file.
>
>The follwing is taken from the dblogfile arround crashtime:
>
>DBSERVER1 (Client) Tue Jun 08 15:25:00 2004
> gds__free: pool corrupted
>DBSERVER1 (Server) Tue Jun 08 15:58:21 2004
> gds__free: attempt to release bad block
>DBSERVER1 (Server) Tue Jun 08 15:58:22 2004
> gds__free: attempt to release bad block
>DBSERVER1 (Server) Tue Jun 08 15:58:51 2004
> INET/inet_error: send errno = 10054
>[...]
>DBSERVER1 (Client) Tue Jun 08 16:00:49 2004
> C:\Program Files\Firebird\bin\ibserver.exe: terminated abnormally
> (-1)
>DBSERVER1 (Client) Tue Jun 08 16:00:49 2004
> INET/inet_error: read errno = 10054
>[...]
>DBSERVER1 (Client) Tue Jun 08 16:00:50 2004
> Guardian starting: C:\Program Files\Firebird\bin\ibserver.exe
>DBSERVER1 (Client) Tue Jun 08 16:00:51 2004
> INET/inet_error: connect errno = 10061
>DBSERVER1 (Client) Tue Jun 08 16:00:55 2004
> INET/inet_error: send errno = 10054
>
>Clould somebody please explain what may have caused the pool to corrupt
>and which pool that is.
>What is this errormessage and it's subsequent attempt "to release badYou are getting log messages that I don't think you should be seeing in the
>block" wanting to tell me?
log in the normal course of events, i.e., something really unexpected is
happening and the engine is doing its best to provide some clues. Whatever
happens next to crash the engine one cannot see, of course, since a crashed
engine can't write log messages.
>DB file seems to be intact by what I take from gfix validate, but willErm, yes, but it could be something that's happening because you are using
>this allways be so after this type of crash?
>
>Also what strikes me as strange is that I'm getting 10054 errors. DB and
>Clients are residing on the same machine. Connection string is
>IP:C:\dbpath\dbfile.fdb ? What might be the cause here. I expected to get
>these messages on "real wire connections" only.
"real wire protocol" to connect, rather than "localhost" (IP address
127.0.0.1) that signals to the network layer that you are in local
loopback. This *could* have something to do with a difference in the
keepalive techniques used for node-to-node connections (your protocol) and
local loopback. A fix was done for the 1.5.1 point release to correct a
crashing problem in 1.5, and the two conditions might be related.
When you report to firebird-devel, mention whether you are using events in
your application. btw, if you are using IBO's DML Caching, then you *are*
using events, under the hood.
Also, do a double-check on the property sheet of gds32.dll to verify that
you have the correct client.
/heLen