Issue Details (XML | Word | Printable)

Key: CORE-5422
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Vlad Khorsun
Reporter: prenosil
Votes: 0
Watchers: 6

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

Decompression overran buffer after rollback

Created: 15/Dec/16 01:07 PM   Updated: 01/Feb/17 06:24 AM
Component/s: None
Affects Version/s: 2.5.0, 2.5.1, 2.5.2, 2.5.2 Update 1, 2.5.3, 2.1.7, 2.5.3 Update 1, 2.5.4, 2.5.5, 4.0 Initial, 3.0.0, 2.5.6, 3.0.1
Fix Version/s: 2.5.7, 3.0.2, 4.0 Alpha 1

Windows Server 2008 R2 64 bit, Windows 10 Pro 64 bit
FB Superserver with GC set to Cooperative

QA Status: Covered by another test(s)
Test Details:
Bug is 100% reproduced on (18-dec-2016), fixed on 27038.
Test already exists - see core_5392.fbt, so i decided only to change there min_version to 2.5.7.
Test Specifics: Architecture (SS/CS) specific

 Description  « Hide
This is the same issue as in (for FB3.0)
and as in (for FB4.0)
(and I have suspition that CORE-5419 is the same problem)

I copied test from CORE-5420 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).

Few notes:
- 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 CORE-5392 works.
- latest snapshot 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;


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 15/Dec/16 02:22 PM
Ivan, just FYI: CORE-5392 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 CORE-5392, 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".

prenosil added a comment - 15/Dec/16 02:39 PM
Sorry, I copy/pasted wrong row, GC should be default one, i.e.
  GCPolicy = combined

Vlad Khorsun added a comment - 06/Jan/17 09:19 AM
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.

Vlad Khorsun added a comment - 06/Jan/17 10:03 AM
could you, please, test next snapshot build of 2.5.7 ?

prenosil added a comment - 10/Jan/17 08:20 AM
Tested intensively by two people, even after several hundreds of cycles the error did not occur any morfe. Thanks a lot.

Vlad Khorsun added a comment - 10/Jan/17 09:11 AM