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

[firebird-automations]

Submitted by: Daniel Bauten (danielbauten)

Votes: 1

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)http://hksinformatik.de 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)

on table K_ACT_AFD_STRING_DATA

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

Daniel

[firebird-automations]

Modified by: Daniel Bauten (danielbauten)

description: 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\. #⁠ Extract \{\{Corrupt table K\_ACT\_AFD\_STRING\_DATA\.7z\}\} \(please note: file is password protected; please mail to Daniel\.Bauten\(a\) to obtain the password\)\. #⁠ running gbak in the following manner \{code\} "%FirebirdPath%\\bin\\gbak\.exe" \-b \-g \-v \-y "%BackupLogFile%" \-user "%User%" \-password "%Password%" "%DatabaseFile%" "%BackupFile%" \{code\} leads into \{code\} gbak: ERROR:internal Firebird consistency check \(decompression overran buffer \(179\), file: sqz\.cpp line: 228\) \{code\} on table \{\{K\_ACT\_AFD\_STRING\_DATA\}\} #⁠ trying \{code\} select count\(\*\) from K\_ACT\_AFD\_STRING\_DATA \{code\} leads into server crash \{code\} internal Firebird consistency check \{code\} Feel free to contact me if you have further questions about this issue\. Thanks in advance for fixing this\. ;\-\) Daniel =\> 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\) on table K\_ACT\_AFD\_STRING\_DATA 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\. ;\-\) Daniel

[firebird-automations]

Commented by: @ibaseru

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.

[firebird-automations]

Commented by: Daniel Bauten (danielbauten)

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.

[firebird-automations]

Commented by: Damyan Ivanov (dam)

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 :)

[firebird-automations]

Commented by: @dyemanov

Firebird *does not* crash in this case. It returns a bugcheck (internal Firebird consistency check) condition which prevents subsequent operations until reconnection.

[firebird-automations]

Commented by: Daniel Bauten (danielbauten)

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.

Daniel

[firebird-automations]

Commented by: @asfernandes

Daniel, as a programmer, how would you make a program that understand a unrecognized (corrupted) file and work fully-functional?

[firebird-automations]

Commented by: @dyemanov

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.

[firebird-automations]

Commented by: Daniel Bauten (danielbauten)

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 (http://www.ib-aid.com). 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. :-(