-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Microsoft.Data.Sqlite.SqliteConnectionPool.GetConnection() fails with "Inconceivable!" on local test run #26016
Labels
area-adonet-sqlite
area-groupby
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
punted-for-6.0
punted-for-7.0
Originally planned for the EF Core 7.0 (EF7) release, but moved out due to resource constraints.
type-bug
Milestone
Comments
/cc @bricelam Could this be due to concurrency issue when using ClearAllPools? If so, we could revert that change for 6.0. |
Hmm, could have been made worse by it, but still probably a legitimate concurrency issue. |
I've done a few builds today and only seen it happen once. |
Has now failed twice more. Overall seems to be failing about 1 in 3 times. |
ajcvickers
added a commit
that referenced
this issue
Sep 16, 2021
Reverted #25797 to get tests running reliably again. |
ajcvickers
added a commit
that referenced
this issue
Sep 16, 2021
ajcvickers
added
punted-for-7.0
Originally planned for the EF Core 7.0 (EF7) release, but moved out due to resource constraints.
and removed
propose-punt
labels
Jul 7, 2022
ajcvickers
added
the
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
label
Dec 14, 2023
ajcvickers
added a commit
that referenced
this issue
Dec 14, 2023
Fixes #25797 Fixes #26016 I identified two race conditions, both caused by splitting state across multiple data structures. In particular, the Semaphore and the two ConcurrentStacks must stay in sync--that is, the Semaphore can let someone get a collection if and only if there is a connection available in the one of the stacks. The fix is to wrap all these things in a single lock. It's possible that we don't need a full lock, but we already have one to protect _collections which can easily be expanded to cover the right areas. Once this lock is used, the semaphore is no longer needed, and the stacks don't need to be concurrent because they are protected by the lock.
ajcvickers
added a commit
that referenced
this issue
Dec 14, 2023
Fixes #25797 Fixes #26016 I identified two race conditions, both caused by splitting state across multiple data structures. In particular, the Semaphore and the two ConcurrentStacks must stay in sync--that is, the Semaphore can let someone get a collection if and only if there is a connection available in the one of the stacks. The fix is to wrap all these things in a single lock. It's possible that we don't need a full lock, but we already have one to protect _collections which can easily be expanded to cover the right areas. Once this lock is used, the semaphore is no longer needed, and the stacks don't need to be concurrent because they are protected by the lock.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-adonet-sqlite
area-groupby
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
punted-for-6.0
punted-for-7.0
Originally planned for the EF Core 7.0 (EF7) release, but moved out due to resource constraints.
type-bug
The text was updated successfully, but these errors were encountered: