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-issue-importer opened this issue Mar 16, 2011 · 5 comments

Comments

@firebird-issue-importer

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 16, 2011

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 17, 2011

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Mar 17, 2011

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 23, 2013

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 18, 2016

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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants