Commented by: @livius2

I can confirm this on Windows but i ca not run this in this sequence
especially i can not run this in the same transaction (from flamerobin)

CREATE DATABASE 'TEST.FDB' user 'SYSDBA' password 'masterkey';
CREATE TABLE A (X INTEGER PRIMARY KEY);
CREATE TABLE B (X INTEGER PRIMARY KEY);
INSERT INTO B VALUES (1);
COMMIT;

table B unknown...

if i change it to

CREATE DATABASE 'TEST.FDB' user 'SYSDBA' password 'masterkey';
CREATE TABLE A (X INTEGER PRIMARY KEY);
CREATE TABLE B (X INTEGER PRIMARY KEY);
COMMIT;
INSERT INTO B VALUES (1);
ALTER TABLE B ADD Y INTEGER REFERENCES A(X);
COMMIT;
DELETE FROM B;
COMMIT;
SELECT COUNT(*) FROM B;

server crashes without entry in log

Commented by: Tim Kelly (m00bh000)

Just to clarify the original test scenario can be proved to fail using ISQL. It was very difficult to isolate the problem as unfortunately the crash does not occur at the point of corruption, but at some point later:

Nb I have since discovered it doesn't matter what table you do a select on, the database is unstable following the delete:

SQL> CREATE DATABASE 'TEST.FDB' user 'SYSDBA' password 'masterkey';
SQL> CREATE TABLE A (X INTEGER PRIMARY KEY);
SQL> CREATE TABLE B (X INTEGER PRIMARY KEY);
SQL> INSERT INTO B VALUES (1);
SQL> COMMIT;
SQL> ALTER TABLE B ADD Y INTEGER REFERENCES A(X);
SQL> COMMIT;
SQL> DELETE FROM B;
SQL> COMMIT;
SQL> SELECT COUNT(*) FROM RDB$DATABASE; <<<< STILL CRASHES EVEN THOUGH SELECTING FROM A DIFFERENT TABLE

I have noticed for some time that my databases seem unstable and can become corrupt following alter statements and suggest whoever looks at this bug also considers CORE4981 / UPDATES / INSERTS / any caches that might need flushing following alters. It is possible that CORE4981 is the same bug. It was a real mission to pin down this test-case, once a fix is made I'll report back if CORE4981 seems to be resolved too. Note in CORE4981 it seemed that disconnecting and restarting server between the alter and table-content manipulation seemed to fix the problem, but I have only had intermittent success with this approach. Furthermore, in one test case on a real database I even managed to still have a corrupt database after a backup and restore between the ALTER and DELETE but I have not been able to reproduce this.