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

isc_dsql_exec_immed2 with zero transaction handle could lead to a BUGCHECK(147) [CORE3389] #3755

Closed
firebird-automations opened this issue Mar 16, 2011 · 5 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @hvlad

I developing a tests using two transactions in the same attachments and found this bug.
Below is log of my test :

DDL: CREATE GLOBAL TEMPORARY TABLE T2 (ID INT) ON COMMIT PRESERVE ROWS
DDL: CREATE UNIQUE INDEX T2_UQ ON T2 (ID)
DDL: COMMIT

tx1: SET TRANSACTION READ COMMITTED NO VERSION NO WAIT
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, column 35
VERSION

tx1: INSERT INTO T2 VALUES (1)
invalid transaction handle (expecting explicit transaction start)

tx2: SET TRANSACTION SNAPSHOT NO WAIT
tx2: INSERT INTO T2 VALUES (1)
tx2: INSERT INTO T2 VALUES (2)
tx1: SELECT COUNT(*) FROM T2
internal Firebird consistency check (invalid block type encountered (147), file: exe.cpp line: 1015)

It was expected to got "invalid transaction handle" error there, not a bugcheck.

Note, i wrongly used "NO VERSION" instead of "NO RECORD_VERSION" therefore start of tx1 failed.

Commits: 6b7e763 293d5dc

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Before DSQL was integrated into the engine in v2.5 it was y-valve who throws isc_bad_trans_handle.
It happens when DSQL tried to prepare statement and queries database.

In v2.5 DSQL called engine directly and few checks for valid transaction was introduced at metd.epp.
But, if object already exists at DSQL cache, this checks is bypassed and we trying to execute request
without a transaction.

In HEAD some checks performed before search in DSQL cache (at least in METD_get_relation) so,
my test case passed v3 successfully. But i see no harm to frontport fix from v2.5 into HEAD too.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.5.1 [ 10333 ]

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

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