Submitted by: @pavel-zotov

Attachments:
broken-fdb-and-logs-of_gfix_v_full___vs___online_validation.7z

1) run following .sql (change path and name of .fdb for your settings):

set list on;
shell del C:\\MIX\\firebird\\QA\\fbt\-repo\\tmp\\c5501\.fdb 2\>nul;
create database 'localhost:C:\\MIX\\firebird\\QA\\fbt\-repo\\tmp\\c5501\.fdb'; \-\- page\_size 8192;
alter database drop linger;
commit;
create table test\(s varchar\(1000\)\);
commit;
set count on;
insert into test\(s\) 
select rpad\( '',1000, uuid\_to\_char\(gen\_uuid\(\)\) \)
from rdb$types
rows 100;
set count off;
commit;
set echo on;
select rdb$linger from rdb$database;
show table test;
select count\(\*\) from test;

===

2) open .fdb in any hex-editor, goto offset = 0x16e000 and ensure that following 16 bytes will be:
05 02 00 00 01 00 00 00 00 00 00 00 b7 00 00 00
(see attach, file "c5501-page_183_healthy_header.png")

3) replace these 16 bytes with:
ff aa cc ee bb 00 00 cc dd ee aa dd cc 00 dd ee
(see attach, file "c5501-page_183_broken_header.png")

4) open batch file "check-db.bat" (see attach) and change settings:

set fbc=C:\MIX\firebird\fb30
set host=localhost
set port=3333
set dbnm=C:\MIX\firebird\QA\fbt-repo\tmp\C5501.FDB
set ISC_USER=SYSDBA
set ISC_PASSWORD=masterkey

5) run "check-db.bat" with argument 0, i.e. type:
check-db.bat 0

This batch being run with argument = 0 will try to launch online validation two times.
Copy its log ("check-db.log") to some other name, say "check-db-online-val.log"

6) run "check-db.bat" with argument 1, i.e. type:
check-db.bat 1
With arg. = 1 this batch will try to launch gfix -v -full, also two times.

Second 'gfix' will fail with error:

bad parameters on attach or create database
-secondary server attachments cannot validate databases

lock-print utility after 1st gfix will show:

LOCK_HEADER BLOCK
...
Owners (4): forward: 187624, backward: 195776 <<<< ONE USER CONNECTION DOES EXIST!
...

Query to MON$ATTACHMENTS show that there is one connection from gfix after it was ran first time and finished its job:

...
MON$STATE 0
MON$ATTACHMENT_ID 11
MON$REMOTE_PROCESS C:\MIX\firebird\fb30\gfix.exe
MON$REMOTE_PROTOCOL TCPv4
MON$USER SYSDBA
MON$SERVER_PID 1828
MON$REMOTE_VERSION P14

Comparison of firebird.log with results of gfix -vs- online validation shows that gfix __did_ fixed one page while online validation not:

1) firebird.log when GFIX was ran for diagnostics:

CSPROG Thu Mar 16 16:05:50 2017
Database: C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C5501.FDB
Error: Page 183 wrong type (expected data encountered unknown (255))
CSPROG Thu Mar 16 16:05:50 2017
Database: C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C5501.FDB
Warning: Pointer page 179 {sequence 0} bits {0x01 full} are not consistent with data page 183 {sequence 0} state {0x05 ull, swept} in table TEST (128)
CSPROG Thu Mar 16 16:05:50 2017
Database: C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C5501.FDB
Warning: Page 183 is an orphan
CSPROG Thu Mar 16 16:05:50 2017
Database: C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C5501.FDB
Validation finished: 1 errors, 2 warnings, 1 fixed <<<<<<<<<<<<<<< "1 FIXED". WHAT exactly was fixed by GFIX -V -FULL?

2) firebird.log when FBSVCMGR ACTION_VALIDATE was ran for diagnostics:

CSPROG Thu Mar 16 16:04:05 2017
Database: C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C5501.FDB
Error: Page 183 wrong type (expected data encountered unknown (255))
CSPROG Thu Mar 16 16:04:05 2017
Database: C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C5501.FDB
Warning: Pointer page 179 {sequence 0} bits {0x01 full} are not consistent with data page 183 {sequence 0} state {0x05 full, swept} in table TEST (128)
CSPROG Thu Mar 16 16:04:05 2017
Database: C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C5501.FDB
Validation finished: 1 errors, 1 warnings, 0 fixed

Checked on WI-V3.0.2.32695, 32 bit, OS = Win XP.