Fix Debug Assertion in Connection Pool Due to Double Deactivation #3587
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Problem: During execution of the test TestAutoEnlistment_TxScopeComplete and TestAutoEnlistment_TxScopeNonComplete in Debug mode,a debug assertion fails: Method Debug.Fail failed with 'activated multiple times? This occurs inside the DeactivateConnection method when returning a connection to the pool after a transaction completes.This assertion failure indicates that the internal _activateCount was already 0 when decrement was attempted again, deactivating the connection more than once. Root Cause: In "TransactionEnded" function,the connection used in a transaction is eventually returned to the general transaction pool via: ```Pool.PutObjectFromTransactedPool(transactedObject);``` The DeactivateConnection function is executed within this function which causes the _activateCount to be decremented a second time, resulting in a negative value and triggering the debug assertion. However,the connection had already been deactivated earlier as part of its transaction enlistment lifecycle There is no subsequent ActivateConnection function for this DeactivateConnection function, which makes the _activateCount to to -1. Fix: We prevent the second DeactivateConnection to decrement the _activateCount counter, by passing the parameter "false" to DeactivateConnection. cc: @uweigand @giritrivedi @saitama951
|
@dotnet-policy-service agree company="IBM" |
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
paulmedynski
requested changes
Sep 5, 2025
src/Microsoft.Data.SqlClient/src/Microsoft/Data/ProviderBase/DbConnectionInternal.cs
Outdated
Show resolved
Hide resolved
src/Microsoft.Data.SqlClient/src/Microsoft/Data/ProviderBase/DbConnectionInternal.cs
Outdated
Show resolved
Hide resolved
|
We've also been having some issues with macOS CI, which should be solved if you rebase or merge main. |
paulmedynski
approved these changes
Sep 8, 2025
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
I'm also working on getting Debug mode PR pipelines to run successfully, and these Asserts() are causing trouble there as well. We will take your improvement, and I will decide whether or not these checks are valuable in my PR. |
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3587 +/- ##
==========================================
- Coverage 63.19% 60.46% -2.74%
==========================================
Files 274 268 -6
Lines 62478 61268 -1210
==========================================
- Hits 39486 37048 -2438
- Misses 22992 24220 +1228
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Can we merge this? |
apoorvdeshmukh
approved these changes
Sep 17, 2025
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a debug assertion failure in the connection pool where DeactivateConnection() was being called twice without a corresponding ActivateConnection() call, causing the _activateCount to decrement below zero.
Key Changes:
- Modified the debug counter decrement logic to prevent double deactivation
- Replaced simple
Interlocked.Decrementwith a compare-and-swap loop that checks for zero before decrementing
src/Microsoft.Data.SqlClient/src/Microsoft/Data/ProviderBase/DbConnectionInternal.cs
Show resolved
Hide resolved
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem:
During execution of the test TestAutoEnlistment_TxScopeComplete and TestAutoEnlistment_TxScopeNonComplete in Debug mode,a debug assertion fails on CoreCLR:
Method Debug.Fail failed with 'activated multiple times?This occurs inside the DeactivateConnection method when returning a connection to the pool after a transaction completes.This assertion failure indicates that the internal _activateCount was already 0 when decrement was attempted again, deactivating the connection more than once.
Root Cause:
In the TransactionEnded function, after a transaction completes, the connection involved is returned to the general pool via:
Pool.PutObjectFromTransactedPool(transactedObject);During this process, DeactivateConnection() is called again. However, the connection had already been deactivated earlier as part of the transaction's enlistment cleanup.This results in DeactivateConnection() being called twice without a corresponding call to ActivateConnection() in between, which causes _activateCount to decrement to -1, triggering the debug assertion.
Fix:
We prevent the second DeactivateConnection to decrement the _activateCount counter, by passing the parameter "false" to DeactivateConnection.
cc: @uweigand @giritrivedi @saitama951