Issue Details (XML | Word | Printable)

Key: CORE-4498
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Pavel Zotov
Votes: 0
Watchers: 0
Operations

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

FB 3.0 crashes when getting an explained plan for a DBKEY based retrieval

Created: 24/Jul/14 11:12 AM   Updated: 23/Sep/15 11:28 AM
Component/s: Engine
Affects Version/s: 3.0 Alpha 2
Fix Version/s: 3.0 Beta 1

QA Status: Done successfully


 Description  « Hide
Simplified test case:

set explain;
select 1 from rdb$relations where rdb$db_key = cast('1234' as char(8) character set octets);


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Pavel Zotov made changes - 24/Jul/14 11:12 AM
Field Original Value New Value
Attachment gdb-firebird.140724_145654.2.zip [ 12560 ]
Dmitry Yemanov made changes - 24/Jul/14 02:12 PM
Assignee Dmitry Yemanov [ dimitr ]
Dmitry Yemanov made changes - 24/Jul/14 02:25 PM
Summary FB 3.0 craches when 1) TRACE is launched *and* 2) run EB with "select ... from T where <C> for update with lock", and it's <C> containing RDB$DBKEY as search criteria FB 3.0 crashes when retrievl an explained plan for DBKEY based retrieval
Description On empty database:
1) launch TRACE (this is mandatory) via tbtracemgr, with config like this:
---
   enabled = true
   time_threshold = 0
   log_statement_finish = true
   print_plan = true
   explain_plan = true
   print_perf = true
   max_sql_length = 16384
   max_log_size = 9999999999
---

2) run the following script:

recreate table t (id bigint not null);
commit;

----------------------------------------------------------

set term ^;
execute block returns( locked_rows int ) as
    declare v_qdbkey char(8) character set octets collate octets;
    declare v_id bigint;
    declare v_stt varchar(30);
begin
  locked_rows = 0;
  v_stt = 'select rdb$db_key,id from t';
  for
        execute statement(v_stt)
        into v_qdbkey, v_id
  do begin
     select id from t where rdb$db_key = :v_qdbkey for update with lock into v_id; -- leads to crach
     -- ok, no crash: select id from t where id = :v_id for update with lock into v_id;
     locked_rows = locked_rows + 1;
  end
  suspend;
end
^ set term ;^
commit;

If this script will be run on LI-T3.0.0.31228, FB will crashes. Stack trace see in attach.

PS. Note:
1) no crash if we replace
    select id from t where rdb$db_key = :v_qdbkey for update with lock into v_id;
    with:
    select id from t where id = :v_id for update with lock into v_id;
2) no crash in FB 2.5 for any case;
3) loop of implicit for-cursor should *NOT* iterate even once since tab;e `t` is EMPTY. Result of script always must be 0, so I can`t understand why any statement inside for-loop can lead to different behaviour (and *only* when trace is ON)
Simplified test case:

set explain;
select 1 from rdb$relations where rdb$db_key = cast('1234' as char(8) character set octets);
Component/s Engine [ 10000 ]
Dmitry Yemanov made changes - 24/Jul/14 02:25 PM
Attachment gdb-firebird.140724_145654.2.zip [ 12560 ]
Dmitry Yemanov made changes - 24/Jul/14 02:26 PM
Summary FB 3.0 crashes when retrievl an explained plan for DBKEY based retrieval FB 3.0 crashes when getting an explained plan for a DBKEY based retrieval
Dmitry Yemanov made changes - 24/Jul/14 07:37 PM
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 3.0 Beta 1 [ 10332 ]
Resolution Fixed [ 1 ]
Pavel Zotov made changes - 29/May/15 09:36 PM
Status Resolved [ 5 ] Resolved [ 5 ]
QA Status Done successfully
Pavel Cisar made changes - 23/Sep/15 11:28 AM
Status Resolved [ 5 ] Closed [ 6 ]