Issue Details (XML | Word | Printable)

Key: CORE-1584
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Claudio Valderrama C.
Votes: 0
Watchers: 0
Operations

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

Server crashed or bugcheck when inserting in monitoring tables.

Created: 09/Nov/07 11:17 PM   Updated: 07/Oct/08 09:50 AM
Component/s: Engine
Affects Version/s: 2.1 Alpha 1, 2.1 Beta 1, 2.0.2, 2.1 Beta 2
Fix Version/s: 2.1 RC1

Time Tracking:
Not Specified

Environment: Platform independent.
Issue Links:
Relate
 


 Description  « Hide
Please don't flame me. I'm trying to behave like an end user.

isql test.fdb
Database: TEST.FDB
SQL> insert into mon$statements values(180, 30, NULL, 0, NULL, 'walking', 15);
Statement failed, SQLCODE = -901
connection lost to database
SQL> ^Z
Statement failed, SQLCODE = -902
Error writing data to the connection.
Statement failed, SQLCODE = -902
Error writing data to the connection.

The server crashed because ERR_punt got getBugcheckAbort() being true. Anyway, the logic is incorrect, because it was triggered by
BUGCHECK(254); in dpm.epp = pointer page vanished from relation list in locate_space.
We should stop undue operations in virtual tables with a proper message much before this.
BTW, why is BugCheckAbort true by default? If I skip it, I get
Statement failed, SQLCODE = -902
internal gds software consistency check (pointer page vanished from relation list in locate_space (2
54), file: dpm.cpp line: 3060)
that's misleading in a virtual table.

In contrast, doing silly things like this produces a good explanation for the user:
SQL> update mon$statements set mon$attachment_id = 8, mon$transaction_id = 23 where mon$statement_id = 5;
Statement failed, SQLCODE = -817
operation not supported
SQL>

C.


 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 - 10/Nov/07 04:54 AM
The bug is because of blob assignment (made before actual insert).
As current implementation of virtual tables don't support insert\update at all its easy to disable blob storage in virtual tables.
May be reconsider later

Claudio Valderrama C. added a comment - 10/Nov/07 05:01 AM
Yes, this is what observed in the call stack.
But isn't the real fix to disable insertions for virtual tables altogether?
Does it make sense to create a new statement by inserting raw values in mon$statements, for example? Virtual tables aren't active system tables, where you define some object and the object is created by DFW.

C.

Claudio Valderrama C. added a comment - 10/Nov/07 05:02 AM
BTW, I still don't understand why BugCheckAbort is true by default instead of the normal BUGCHECK behavior.
Maybe only in DEV_BUILD or my config file is screwed?

C.

Vlad Khorsun added a comment - 10/Nov/07 05:11 AM
> But isn't the real fix to disable insertions for virtual tables altogether?
Its disabled already ;) Look at VirtualTable::store (called from exe\store)
But blob assignments performed _before_ exe\store

> BTW, I still don't understand why BugCheckAbort is true by default instead of the normal BUGCHECK behavior.
> Maybe only in DEV_BUILD or my config file is screwed?

Yes, in DEV_BUILD BugCheckAbort is true by default : look at common\config\config.cpp

Philippe Makowski added a comment - 07/Oct/08 09:50 AM
Q/A test ok