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

Engine crashes if the NULL attachment handle is passed from the Y-valve [CORE2840] #3226

Closed
firebird-automations opened this issue Feb 2, 2010 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @dyemanov

The issue becomes possible when multiple threads execute the isc_detach_database() call at the same time. It can be reproduced with:

delete from mon$attachments where mon$attachment_id <> current_connection

running against a concurrently loaded server. I tried 20 TPC-C connections.

It seems being a regression introduced in RC1.

Commits: 2cc6811 2497723

====== Test Details ======

What kind of workload needs to be created ? How long sessions should work before they will be killed ?

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => In Progress [ 3 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 2.5 RC2 [ 10372 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

description: The issue becomes possible when multiple threads execute the isc_detach_database() call at the same time. It can be reproduced with:

delete from mon$attachments where mon$attachment_id <> current_connection

running against a concurrently loaded server. I tried 20 TPC-C connections.

=>

The issue becomes possible when multiple threads execute the isc_detach_database() call at the same time. It can be reproduced with:

delete from mon$attachments where mon$attachment_id <> current_connection

running against a concurrently loaded server. I tried 20 TPC-C connections.

It seems being a regression introduced in RC1.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: In Progress [ 3 ] => Open [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

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

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: No test => Not enough information

Test Details: What kind of workload needs to be created ? How long sessions should work before they will be killed ?

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