Server crashed or bugcheck when inserting in monitoring tables. [CORE1584]

[firebird-automations]

Submitted by: Claudio Valderrama C. (robocop)

Is related to QA202

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.

Commits: b38d29c

[firebird-automations]

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

[firebird-automations]

Commented by: @hvlad

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

[firebird-automations]

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.1 RC1 [ 10201 ]

[firebird-automations]

Commented by: Claudio Valderrama C. (robocop)

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.

[firebird-automations]

Commented by: Claudio Valderrama C. (robocop)

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.

[firebird-automations]

Commented by: @hvlad

> 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

[firebird-automations]

Modified by: @pcisar

Link: This issue is related to QA202 [ QA202 ]

[firebird-automations]

Modified by: @pcisar

Workflow: jira [ 13399 ] => Firebird [ 14066 ]

[firebird-automations]

Commented by: @pmakowski

Q/A test ok

[firebird-automations]

Modified by: @pmakowski

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

[firebird-automations]

Modified by: @pavel-zotov

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

QA Status: Done successfully