Issue Details (XML | Word | Printable)

Key: CORE-3389
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 0
Watchers: 0
Operations

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

isc_dsql_exec_immed2 with zero transaction handle could lead to a BUGCHECK(147)

Created: 16/Mar/11 08:41 PM   Updated: 23/Apr/13 11:47 AM
Component/s: Engine
Affects Version/s: 2.5.0
Fix Version/s: 2.5.1, 3.0 Alpha 1

Time Tracking:
Not Specified

Planning Status: Unspecified


 Description  « Hide
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.


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 16/Mar/11 09:16 PM
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.