You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Transaction object releases unmanaged memory in Dispose or in finalizer if a client fails to call Dispose. When a client calls Dispose, the transaction object removes itself from .Net finalization queue for the sake of performance.
Later, if we call Transaction.Restart on the disposed transaction, it allocates a new transaction, but doesn't put itself back in the finalization queue, thus making it possible to leak a memory if a client doesn't call Dispose again.
Either restarting of a disposed transaction should be prohibited or the transaction should be kept in the finalization queue in such scenario.
Reproduction code snippet
The text was updated successfully, but these errors were encountered:
Worth mentioning. The issue is not something artificial - it's a kind of behavior Starcounter.Palindrom shows due to a yet unrevealed race condition. Using a disposed transaction object is ofc a bug on Starcounter.Palindrom side, but it shouldn't have such severe consequences as a memory leak.
Starcounter version:
3.0
.Issue type
Issue description
Transaction object releases unmanaged memory in
Dispose
or in finalizer if a client fails to callDispose
. When a client callsDispose
, the transaction object removes itself from .Net finalization queue for the sake of performance.Later, if we call
Transaction.Restart
on the disposed transaction, it allocates a new transaction, but doesn't put itself back in the finalization queue, thus making it possible to leak a memory if a client doesn't callDispose
again.Either restarting of a disposed transaction should be prohibited or the transaction should be kept in the finalization queue in such scenario.
Reproduction code snippet
The text was updated successfully, but these errors were encountered: