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
Bugcheck 167 (invalid SEND request) while working with GTT from several attachments (using EXECUTE STATEMENT ... ON EXTERNAL and different roles) [CORE4754] #5058
Comments
Modified by: @pavel-zotovAttachment: fb-abend-after-manupilations-with-GTT-using-ES-in-several-attaches-from-single-execute-block.zip [ 12706 ] |
Modified by: @hvladassignee: Vlad Khorsun [ hvlad ] |
Commented by: @hvlad It should be reproducible in all FB versions where GTT is present |
Commented by: @hvlad Fix is committed into v3, please confirm |
Commented by: @pavel-zotov Works OK on LI-T6.3.0.31797, revision 61367 (checked on SS & SC). |
Commented by: @hvlad Thanks. Fix for v2.5 backported |
Modified by: @hvladstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0 Beta 2 [ 10586 ] Fix Version: 2.5.5 [ 10670 ] |
Commented by: @pavel-zotov Tested on WI-V6.3.5.26861 (SC and SS) -- works fine. |
Modified by: @dyemanovsummary: Manipulations with GTT from several attachments (using ES/EDS and different roles) leads to: "internal Firebird consistency check (invalid SEND request (167), file: JrdStatement.cpp line: 325)" => Bugcheck 167 (invalid SEND request) while working with GTT from several attachments (using EXECUTE STATEMENT ... ON EXTERNAL and different roles) |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Submitted by: @pavel-zotov
Attachments:
fb-abend-after-manupilations-with-GTT-using-ES-in-several-attaches-from-single-execute-block.zip
WI-T3.0.0.31789, reproduced in SuperServer and SuperClassic.
The following script:
recreate global temporary table gtt_session(x int, y int) on commit preserve rows;
commit;
set transaction read committed;
set term ^;
execute block as -- returns(att_id int, cnt int, sql_plan blob, idx_stat double precision) as
declare v_dbname type of column mon$database.mon$database_name;
begin
v_dbname = 'localhost:' || rdb$get_context('SYSTEM', 'DB_NAME');
execute statement 'insert into gtt_session select rand()*10, rand()*10 from rdb$types union all select -2, -3 from rdb$database'
on external v_dbname
as user 'sysdba' password 'masterke' role 'poor_dba';
--------------------------------------------------------
execute statement 'insert into gtt_session select rand()*10, rand()*10 from rdb$types union all select -2, -3 from rdb$database'
on external v_dbname
as user 'sysdba' password 'masterke' role 'cool_dba';
execute statement 'create index gtt_session_x_y on gtt_session computed by ( x+y )'
with autonomous transaction
on external v_dbname
as user 'sysdba' password 'masterke' role 'cool_dba';
--------------------------------------------------------
execute statement 'insert into gtt_session select rand()*10, rand()*10 from rdb$types union all select -2, -3 from rdb$database'
on external v_dbname
as user 'sysdba' password 'masterke' role 'super_dba';
end
^
set term ;^
-- leads to:
1) appearing in firebird.log message:
CSPROG Fri Apr 17 21:24:38 2015
Database: C:\MIX\firebird\QA\fbt-repo\tmp\e30.fdb
internal Firebird consistency check (invalid SEND request (167), file: JrdStatement.cpp line: 325)
2) appearing 'abend message' on Windows XP with:
2.1) singnature of error:
szAppName : firebird.exe szAppVer : 3.0.0.31789 szModName : msvcr100.dll
szModVer : 10.0.30319.415 offset : 0008cb95
2.2) notion about two files (which have been attached here): firebird.exe.mdmp and appcompat.txt
3) After this message will appear:
3.1) ISQL can not finish script, and can not be interrupted;
3.2) no new attaches can be etsablished to any other .fdb
3.3) these ISQLs loads CPU up to 100% and also can not be interrupted - even after killing firebird process.
All necessary files please see in attached .zip
Commits: 8b7c62d 5186bff FirebirdSQL/fbt-repository@618776b FirebirdSQL/fbt-repository@98f5d79
The text was updated successfully, but these errors were encountered: