Issue Details (XML | Word | Printable)

Key: CORE-6379
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

Bugcheck 179

Created: 04/Aug/20 12:15 PM   Updated: 20/Aug/20 08:55 PM
Component/s: Engine
Affects Version/s: 4.0 Beta 2
Fix Version/s: 4.0 RC 1

QA Status: Done successfully

 Description  « Hide
The bug was detected and reproduced when testing new fb4 feature (statement restart on update conflict) but its reason is present in all Firebird versions.

To reproduce start two isql sessions against same database with page size 8KB

isql 1:
recreate table t5(id int generated by default as identity, x int, s varchar(32765) );
insert into t5(x, s) select first 10 0, lpad('', 32765, gen_uuid()) from rdb$types;

update t5 set x = -1111 where id = 3;

isql 2:
set autoddl off;

set transaction read committed read consistency;
delete from t5;
-- waits for transaction in isql 1

isql 1:

at this point isql 2 will print:

Statement failed, SQLSTATE = XX000
Error during savepoint backout - transaction invalidated
-internal Firebird consistency check (decompression overran buffer (179), file: sqz.cpp line: 293)
Statement failed, SQLSTATE = XX000
internal Firebird consistency check (can't continue after bugcheck)

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 04/Aug/20 12:22 PM
The bug reason is wrong space allocation on data page when fragmented record is deleted.
The space allocated for delete stub is too small and later, when delete is undo-ed, restored record version could overwrite few bytes of adjacent next record version.

Unfortunately (or happily), I can't reproduce it on previous versions of Firebird (fb3 and older) but it doesn't mean it can't happen there.