Issue Details (XML | Word | Printable)

Key: CORE-6015
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 1
Operations

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

Segfault when using expression index with complex expression

Created: 01/Mar/19 09:55 AM   Updated: 07/Mar/19 07:38 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, 2.5.7, 3.0.2, 4.0 Alpha 1, 2.5.8, 3.0.3, 3.0.4, 4.0 Beta 1
Fix Version/s: 2.5.9, 3.0.5, 4.0 Beta 2

QA Status: Deferred
Test Details: See comment 07/Mar/19 07:38 AM


 Description  « Hide
Nothing limits use of rather complex expression in the index. One can use selectable stored procedure to calculate that expression, and in that stored procedure one can select rows from the table on which expression index is created. During garbage collection of such index key value is calculated which causes expression evaluation, execution of SP and tabke scan - which in turn causes GC. I.e. we have unlimited recursion with obvious stack overflow and segfault.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 01/Mar/19 10:04 AM
Explicitly disable further GC when doing any index GC.

Pavel Zotov added a comment - 07/Mar/19 07:38 AM
Run following script (replace "C:\FBTESTING\qa\misc\c6015.fdb" with your env.):
=====
    set bail on;
    set echo on;

    shell del C:\FBTESTING\qa\misc\c6015.fdb 2>nul;
    create database 'localhost:C:\FBTESTING\qa\misc\c6015.fdb' user 'SYSDBA' password 'masterkey';
    show version;

    create sequence g;
    set term ^;
    create procedure sp_eval(a_id int) returns(x_cnt int) as
    begin
       suspend;
    end^
    set term ;^
    commit;
    create table test(id int primary key, x int);
    create index test_eval_1 on test computed by ( ( select x_cnt from sp_eval(x) ) );
    commit;

    insert into test(id, x) values(1, 111);
    insert into test(id, x) values(2, 222);
    commit;

    -- Prevent from appearing "Modifying procedure SP_EVAL which is currently in use by active user requests" in FB log:
    connect 'localhost:C:\FBTESTING\qa\misc\c6015.fdb' user 'SYSDBA' password 'masterkey';

    set term ^;
    alter procedure sp_eval(a_id int) returns(x_cnt int) as
    begin

       update test set x = -x
       --where id = :a_id
       order by x rows 1
       returning x into x_cnt ;

       suspend;
    end^
    set term ;^
    commit;

    set transaction read committed;
    set plan on;

    /*
    -- case-1:
    -- =======
    select
        t.id as id_case_1
        ,t.x as x_case_1
        ,( select * from sp_eval( t.id ) )
    from test t
    ;
    --*/


    /*
    -- case-2:
    -- =======
    select
        t.id as id_case_2
        ,t.x as x_case_2
    from test t
    left join sp_eval( t.id ) on 1=1
    ;
    --*/


    --/*
    -- case-3:
    -- =======
    select
        t.id as id_case_3
        ,t.x as x_case_3
    from test t
    where exists( select 1 from sp_eval( t.id ) )
    ;
    --*/
    quit;
=====

All of cases (1,2,3) that are in this script lead FB to crash.
Checked on 2.5.9.27129, 3.0.5.33109 and 4.0.0.1457

Dumps, stack traces and snapshots with .pdb files can be found here:

https://drive.google.com/open?id=1odge6pliSlieYrkJiTnEplnfX7mr68me