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
Comments
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). 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 |
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. |
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. |
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 :) |
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. |
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 |
Commented by: @asfernandes Daniel, as a programmer, how would you make a program that understand a unrecognized (corrupted) file and work fully-functional? |
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. |
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. :-( |
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
The text was updated successfully, but these errors were encountered: