Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FB 3.0 crashes when getting an explained plan for a DBKEY based retrieval [CORE4498] #4817

Closed
firebird-automations opened this issue Jul 24, 2014 · 8 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pavel-zotov

Simplified test case:

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

Commits: 7f90a39 FirebirdSQL/fbt-repository@0492ad1

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

Attachment: gdb-firebird.140724_145654.2.zip [ 12560 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Component: Engine [ 10000 ]

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);

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Attachment: gdb-firebird.140724_145654.2.zip [ 12560 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0 Beta 1 [ 10332 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: Done successfully

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants