Subject | Re: [firebird-support] Please Help ---> Security.Fdb Damaged |
---|---|
Author | Ann W. Harrison |
Post date | 2006-08-02T04:03:41Z |
jorge_mosquera wrote:
suggest shutting down the database server and rebooting the machine.
Before starting the database server, make copies of the security
database and all user databases. Then restart the database server
and the problem will probably have gone away.
The phrase "internal gds software consistency check" means that
the engineer working there didn't want to create a normal error
message that's got its own number & mnemonic and can be translated,
so used the default "oh my god, it's on fire" error code plus a
hard-coded string. That's a lot easier, but you really have to
understand the phrase in parenthesis because that's the message
intended.
"Non-zero use count of a buffer in the empty que" is interesting.
Firebird does its own internal memory allocation instead of
calling malloc and free - or new and delete - for each block
used. There's a huge performance gain. The memory allocator
keeps queues of small blocks that have been released rather than
recombining them. Small blocks tend to be reused a lot. To
avoid disaster, each block has a use count. If you reference
it, you increment it. When you don't care about it any more,
you decrement it. If you forget and go away, the reference
count left as non-zero, and you're in big trouble with the
memory allocator gods.
So, probably, on some obscure code path, there's a memory
reference that's not cleaning up its use count. Of course,
it could be a write beyond the limits of one block that
trashed the use count of a subsequent block. Or some other
error.
The good news is that all those errors are in memory and
should not have actually corrupted the database on disk, so
when you restart the server, all should be well. But, since
you wrote to the list, you've probably tried rebooting without
success. If that's the case, ask again and we'll try to
figure out how to fix whatever is wrong on disk.
Cheers,
Ann
> SERVER (Server) Tue Aug 01 15:26:37 2006That something is wrong with the memory allocation mechanism. I'd
> Database: C:\PROGRAM FILES\FIREBIRD\FIREBIRD_1_5\SECURITY.FDB
> internal gds software consistency check (Non-zero use_count of a
> buffer in the empty que (301))
>
> What this mean ?
suggest shutting down the database server and rebooting the machine.
Before starting the database server, make copies of the security
database and all user databases. Then restart the database server
and the problem will probably have gone away.
The phrase "internal gds software consistency check" means that
the engineer working there didn't want to create a normal error
message that's got its own number & mnemonic and can be translated,
so used the default "oh my god, it's on fire" error code plus a
hard-coded string. That's a lot easier, but you really have to
understand the phrase in parenthesis because that's the message
intended.
"Non-zero use count of a buffer in the empty que" is interesting.
Firebird does its own internal memory allocation instead of
calling malloc and free - or new and delete - for each block
used. There's a huge performance gain. The memory allocator
keeps queues of small blocks that have been released rather than
recombining them. Small blocks tend to be reused a lot. To
avoid disaster, each block has a use count. If you reference
it, you increment it. When you don't care about it any more,
you decrement it. If you forget and go away, the reference
count left as non-zero, and you're in big trouble with the
memory allocator gods.
So, probably, on some obscure code path, there's a memory
reference that's not cleaning up its use count. Of course,
it could be a write beyond the limits of one block that
trashed the use count of a subsequent block. Or some other
error.
The good news is that all those errors are in memory and
should not have actually corrupted the database on disk, so
when you restart the server, all should be well. But, since
you wrote to the list, you've probably tried rebooting without
success. If that's the case, ask again and we'll try to
figure out how to fix whatever is wrong on disk.
Cheers,
Ann