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

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

Closed
firebird-automations opened this issue Nov 10, 2007 · 11 comments

Comments

@firebird-automations
Copy link
Collaborator

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
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.1 RC1 [ 10201 ]

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA202 [ QA202 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Commented by: @pmakowski

Q/A test ok

@firebird-automations
Copy link
Collaborator Author

Modified by: @pmakowski

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: Done successfully

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment