Issue Details (XML | Word | Printable)

Key: CORE-3865
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Daniel Bauten
Votes: 1
Watchers: 4

If you were logged in you would be able to see more operations.
Firebird Core

Bugcheck 179 (decompression overran buffer) on backup and server crash (internal Firebird consistency check) on selecting records

Created: 12/Jun/12 01:43 PM   Updated: 13/Jun/12 11:41 AM
Component/s: Engine, GBAK
Affects Version/s: 2.5.1
Fix Version/s: None

Environment: Firebird x64, Windows 7 Professional 64-Bit (German), 4 GB RAM

 Description  « Hide
The table K_ACT_AFD_STRING_DATA seems to be corrupt. Therefore, backing up the database is not possible, i.e. leads into Bugcheck 179 (decompression overran buffer). Selecting all records of K_ACT_AFD_STRING_DATA leads into internal Firebird consistency check.


To reprocude, please do the following.

1. Extract Corrupt table K_ACT_AFD_STRING_DATA.7z (please note: the file is about 47 MB; please send an mail to Daniel.Bauten(a) so I can upload the file somewhere).

2. Running gbak in the following manner

"%FirebirdPath%\bin\gbak.exe" -b -g -v -y "%BackupLogFile%" -user "%User%" -password "%Password%" "%DatabaseFile%" "%BackupFile%"

leads into

gbak: ERROR:internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: 228)


3. Trying

select count(*) from K_ACT_AFD_STRING_DATA

leads into server crash

internal Firebird consistency check


Feel free to contact me if you have further questions about this issue.

Thanks in advance for fixing this. ;-)


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
kdv added a comment - 12/Jun/12 01:57 PM
why you think that this is a bug? database corruption can be the result of lot of hardware issues.

And "to reproduce" is not reproducing the bug, it's reproducing the engine behavior when it tries to read corrupted data.

Daniel Bauten added a comment - 12/Jun/12 02:09 PM
I know that this behavior is not bug - but probably the result of a bug. But even when it is neither a bug nor a "wrong behavior" - the database can not be used anymore.

I think it would be helpful if Firebird would not crash in this case and just would skip all unreadable records on backup. Therefore my issue would be a feature request.

If there is any way to "repair" the database, it would be great.

Damyan Ivanov added a comment - 13/Jun/12 05:48 AM
kdv, a database engine should not crash, ever. Instead, it should return error.

Firebird already returns errors for other corruptions, so this is not something entirely new :)

Dmitry Yemanov added a comment - 13/Jun/12 05:58 AM
Firebird *does not* crash in this case. It returns a bugcheck (internal Firebird consistency check) condition which prevents subsequent operations until reconnection.

Daniel Bauten added a comment - 13/Jun/12 06:07 AM
Dear Dmitry,

OK, I understand that this is not a "crash". But whatever we call it - how can I backup and restore this database?

Is it conceivable to extend gbak that corrupt parts are skipped on backup?

What else could be a solution?

Thanks in advance.


Adriano dos Santos Fernandes added a comment - 13/Jun/12 10:49 AM
Daniel, as a programmer, how would you make a program that understand a unrecognized (corrupted) file and work fully-functional?

Dmitry Yemanov added a comment - 13/Jun/12 10:59 AM
In the real world, skipping "damaged" records could be impossible, if corruption affects more than just a few bytes. And attempting to do so could *really* crash the server.

Daniel Bauten added a comment - 13/Jun/12 11:09 AM - edited
Adriano and Dmitry, I do not expect a fully-functional working for a corrupt database.

I tried out "FirstAID 3.0 Data Extractor Beta" sent to me by the IBSurgeon Support Team ( This tool is able to read the not corrupted parts of the table to extract them. It might not help for every corruption but it does on my database.

Therefore it would be great if gbak would be able to do the same, i.e. extract the recognized (not corrupted) parts of the data. Shall I post this as a feature request for gbak?

If you say that this is not possible - well, I have to cope with it. But it is hard to explain to our customers that their database is broken and they have to fall back to some backup. :-(