This is the same issue as in (for FB3.0) CORE5392
and as in (for FB4.0) CORE5420
(and I have suspition that CORE5419 is the same problem)
I copied test from CORE5420 with some minor changes (adding primary key is removed because it is unnecessary, and force write is set ON (in my tests on FB2.5.6 i can''t reproduce the crash with FW OFF).
- probalibity of crash is higher with CpuAffinityMask = 1 than with CpuAffinityMask = 0
- when testing on real table/data, the crash occur even without "alter table test add ..."
- after exactly 2 minutes after "Decompression overran" there is "deadlock" in fbirebird.log
- no error occurs when
- GC is turned off in connect string (isc_dpb_no_garbage_collect), or
- GC set to Cooperative in .conf, or
- using Embedded version
- when testing night FB3.0 snapshot the problem seems fixed (did not occur even after >400 runs of test scripts), i.e. fix from CORE5392 works.
- latest snapshot 22.214.171.124030-0_x64 crashes too
shell del E:\TEMP\Test.fdb 2>nul;
create database 'localhost:E:\TEMP\Test.fdb';
connect 'localhost:E:\TEMP\Test.fdb' no garbage_collect;
create domain dm_longutf as varchar(8000) character set utf8;
recreate table test (id int not null, a int);
set echo on;
set term ^;
execute block as
declare i int;
declare n int = 100000;
while (n>0) do insert into test(id, a) values(:n, :n) returning :n-1 into n;
set term ;^
alter table test add b dm_longutf default '' not null;
update test set a=2;
set list on;
-- this lead to decompression overran buffer (179), file: sqz.cpp line: 282
set echo on;
update test set a=3;
Ivan, just FYI: CORE5392 was a regression, the problematic code does not exist in v2.x. So it seems that v2.5 also has races with background GC thread that can lead to the same issue, but the reason is somewhat different (although possibly related). Thus so far I doubt it's fixed by the patch for CORE5392, maybe it's just hidden in v3 now.
BTW, is the "Enviroment" ticket field really correct? Based on your description, it should rather contain "GC set to Mixed / Background".
Looking at bug nature and a patch (just committed into B2_5_Release) i'd say it is very old.
Probably it was somehow hidden before.
Must note, that i couldn't reproduce it until affinity mask was set to use more than one core.