Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
firebird-automations opened this issue Jun 12, 2012 · 9 comments

Comments

@firebird-automations
Copy link
Collaborator

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
Copy link
Collaborator Author

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)http://hksinformatik.de 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)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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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. :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant