Open ondrap opened 1 year ago
@ondrap This issue seems to be even more prevalent on newer GHC versions (e.g. 9.4.5) and statements seem to be affected as well. Additionally the NOINLINE
workaround doesn't seem to work anymore.
Hello, I had a similar issue when upgrading from GHC 8.6 to 9.4.8.
I believed I've finally fixed the issue (had "Tried to use a disposed ODBC Statement" and sometimes the same about the connection handle) and finally had a break-through.
I've taken inspiration from this post recommending to attach the finalize to an embedded IORef:
https://discourse.haskell.org/t/using-the-garbage-collector-to-free-user-resources/5532/5
And reproduced the reaperRef
pattern from:
https://hackage.haskell.org/package/resource-pool-0.4.0.0/docs/src/Data.Pool.Internal.html#newPool
It's only using the reaperRef pattern that I had a definite improvement. My previous tries were:
-fno-cse
StrictData
extensionIO
functions in .hsc
files__attribute__((noline))
in the cbits functionsmodifyMVar
expressionsThough the stability improvement from my changes may be due to a mix of all this, I have yet to test whether any change besides the reaper ref ones are actually crucial
@flhorizon: I've replaced all calls to addFinalizer
with mkWeakMVar
on the relevant MVars. It seems to work well with several GHC versions.
@ak-coram Nice to know !
I tried to upgrade my compiler to ghc 9.2.5 and the who thing just stopped working. Ultimately, I found that the
freeDbcIfNotAlready
is being started practically at the first GC cycle. It seems the compiler was able to optimize the structure out by inlining the functions so that in the end there was nothing pointing to theDbcWrapper
.Marking one of the function that use the wrapper
NOINLINE
seems to help; though, it seems to me some other solution might be well preferable (in the end, using some kind ofwith
function usually works better).