Firebird 6.0. Crash during multi-threaded database restore

[sim1984]

The error occurs randomly and may not reproduce during a subsequent restore. It always occurs during the index building phase, but in different places.

gbak -c -V -user SYSDBA -pas masterkey -par 2 -st TD -se inet://localhost:3056/service_mgr d:\fbdata\5.0\billing.fbk d:\fbdata\6.0\billing.fdb -Y d:\fbdata\6.0\billing-restore.log

...
gbak:   77.173  8.600 creating indexes
gbak:   77.233  0.059 committing metadata
gbak:   77.310  0.076     activating and creating deferred index "PUBLIC"."PK_USER_SECURITY_FLAGS"
gbak:   77.312  0.002     activating and creating deferred index "PUBLIC"."PK_PAY_NOTIFY"
gbak:   77.314  0.001     activating and creating deferred index "PUBLIC"."PK_API_LOG"
gbak:   77.316  0.001     activating and creating deferred index "PUBLIC"."IDX_API_LOG_BYDATE_DESC"
gbak:   77.317  0.001     activating and creating deferred index "PUBLIC"."PK_API_POINT"
gbak:   77.318  0.001     activating and creating deferred index "PUBLIC"."UK_API_POINT_NAME"
gbak:   77.319  0.001     activating and creating deferred index "PUBLIC"."UK_API_POINT_KEY_VALUE"
gbak:   77.320  0.001     activating and creating deferred index "PUBLIC"."PK_PAGE_CATEGORY"
gbak:   77.322  0.001     activating and creating deferred index "PUBLIC"."PK_ETNI_DB_LINKS"
gbak:   77.323  0.001     activating and creating deferred index "PUBLIC"."UK_DB_LINK_NAME"
gbak:   77.324  0.001     activating and creating deferred index "PUBLIC"."IDX_ETNI_DB_LINKS_DATABASE"
gbak:   77.325  0.001     activating and creating deferred index "PUBLIC"."PK_USER_FARMS"
gbak:   77.326  0.001     activating and creating deferred index "PUBLIC"."UK_USER_FARMS"
gbak:   77.328  0.001     activating and creating deferred index "PUBLIC"."IDX_UF_CODE_FARM"
gbak:   77.329  0.001     activating and creating deferred index "PUBLIC"."UNQ_WEBUSER_LOGIN"
gbak:   77.365  0.035     activating and creating deferred index "PUBLIC"."WEBUSER_IDX_BYDATE"
gbak:   77.377  0.012     activating and creating deferred index "PUBLIC"."WEBUSER_IDX_BYDATE_DESC"
gbak:   77.390  0.012     activating and creating deferred index "PUBLIC"."PK_WEBUSER"
gbak:   77.403  0.013     activating and creating deferred index "PUBLIC"."IDX_WEBUSER_EMAIL"
gbak:   77.424  0.020     activating and creating deferred index "PUBLIC"."UNQ_WEBUSER_ACTIVE_EMAIL"
gbak:   77.444  0.020     activating and creating deferred index "PUBLIC"."IDX_USER_LOGINS_BYDATE"
gbak:cannot commit index "PUBLIC"."IDX_USER_LOGINS_BYDATE"
gbak: ERROR:I/O error during "ReadFile" operation for file "D:\FBDATA\6.0\BILLING.FDB"
gbak: ERROR:    Error while trying to read from file
gbak: ERROR:    Неверный дескриптор. 
gbak: ERROR:internal Firebird consistency check (can't continue after bugcheck)

[sim1984]

If you open the damaged database after recovery and execute:

ALTER INDEX IDX_USER_LOGINS_BYDATE ACTIVE;

then the problematic index is built successfully.

[tomaszdubiel18]

Given that this is an I/O error, does this error also occur on another server? I would typically say there is something wrong with disks.
"invalid descriptor"

[hvlad]

There must be record in firebird.log about bugcheck. Weird that gbak doesn't report it.

gbak: ERROR:I/O error during "ReadFile" operation for file "D:\FBDATA\6.0\BILLING.FDB"
gbak: ERROR: Error while trying to read from file
gbak: ERROR: Неверный дескриптор.

This is consequence of bugcheck - engine closed database file immediately and pending IO requests failed with this message.

gbak: ERROR:internal Firebird consistency check (can't continue after bugcheck)

Any action with bugchecked database (except of detach) throws this error.

[sim1984]

firebird.log

Database 1:

DESKTOP-MCH5AOF	Wed May 13 10:02:34 2026
	I/O error during "ReadFile" operation for file "D:\FBDATA\6.0\HORSES.FDB"
	Error while trying to read from file
	Неверный дескриптор. 


DESKTOP-MCH5AOF	Wed May 13 10:02:34 2026
	Database: D:\FBDATA\6.0\HORSES.FDB
	I/O error during "ReadFile" operation for file "D:\FBDATA\6.0\HORSES.FDB"
	Error while trying to read from file
	Неверный дескриптор. 


DESKTOP-MCH5AOF	Wed May 13 10:02:34 2026
	Database: D:\FBDATA\6.0\HORSES.FDB
	internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: 502)

Database 2:

DESKTOP-MCH5AOF	Wed May 13 10:09:34 2026
	I/O error during "ReadFile" operation for file "D:\FBDATA\6.0\BILLING.FDB"
	Error while trying to read from file
	Неверный дескриптор. 


DESKTOP-MCH5AOF	Wed May 13 10:09:34 2026
	Database: D:\FBDATA\6.0\BILLING.FDB
	I/O error during "ReadFile" operation for file "D:\FBDATA\6.0\BILLING.FDB"
	Error while trying to read from file
	Неверный дескриптор. 

DESKTOP-MCH5AOF	Wed May 13 10:09:34 2026
	Database: D:\FBDATA\6.0\BILLING.FDB
	internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: 493)

For another database, it occurs in a different location. What these two errors have in common is that they may not occur at all.

[hvlad]

The error occurs randomly and may not reproduce during a subsequent restore. It always occurs during the index building phase, but in different places.
...
For another database, it occurs in a different location. What these two errors have in common is that they may not occur at all.

You mean - for different tables ? Or for different indices of the same table ? Or different line in sqz.cpp ?
Does these table(s) have computed fields ?

If you open the damaged database after recovery and execute:

ALTER INDEX IDX_USER_LOGINS_BYDATE ACTIVE;

then the problematic index is built successfully.

What you mean - recovery ? Validation by gfix ? What it wrote into firebird.log ?

[sim1984]

The error occurs randomly and may not reproduce during a subsequent restore. It always occurs during the index building phase, but in different places.
...
For another database, it occurs in a different location. What these two errors have in common is that they may not occur at all.

You mean - for different tables ? Or for different indices of the same table ? Or different line in sqz.cpp ?

• different line in sqz.cpp

Does these table(s) have computed fields ?

No.

If you open the damaged database after recovery and execute:
ALTER INDEX IDX_USER_LOGINS_BYDATE ACTIVE;
then the problematic index is built successfully.

What you mean - recovery ? Validation by gfix ? What it wrote into firebird.log ?

I simply opened the database after gbak restore failed.
I then ran the command successfully with a commit.

[hvlad]

You mean - for different tables ? Or for different indices of the same table ? Or different line in sqz.cpp ?

* different line in sqz.cpp

So, same table and index (first one for the table) every time ?
Could you try restore with -one_at_time switch ?

Or, could you provide me with such a backup to try to reproduce the issue ?

[sim1984]

So, same table and index (first one for the table) every time ?

No. The error occurs in different databases. It can occur on different indexes of the same database. And even for different tables (provided the table isn't tiny).

Could you try restore with -one_at_time switch ?

I can, but it won't do anything. I've already run a second restore, and it successfully restored both the first and second databases. So there's some random factor there. But it's pretty easy to reproduce. I think the probability of reproducing the error increases as N increases -par N.

Or, could you provide me with such a backup to try to reproduce the issue ?

I'll upload it to Google Drive and send you links in an email.

[sim1984]

I sent both backups.

[hvlad]

Fixed at 0be199f