On Monday, 12 January 2015 at 11:04:45 UTC, francesco.cattoglio
wrote:
On Sunday, 11 January 2015 at 19:30:59 UTC, ponce wrote:
When does invalidMemoryOperationError happen and how do you
avoid it?
Typical example:
using (a slightly outdated version of) gfm library, I have few
gfm objects lying around on which I forget to call a close()
function. When the GC collects them the destructor runs
close(), which in turn calls for some allocation (e.g:
allocates for a string to send to the logger),
invalidMemoryOperationError pops up.
This usually only happens at the end of execution, sometimes
however it happens randomly during program execution due to the
randomness of GC operations.
The only way out of this is manually closing everything
correctly. I.e: I'm almost back to C++ manual memory
management. Catching the exception is an unsatisfactory
solution because I would still be leaking resources[1]. If
possible, things are made even worse in that RefCounted doesn't
work for classes, but that you can work around that (class
instance into refcounted struct, not really elegant and
requires lots of discipline, since it's easy to escape an extra
reference).
[1] For everyone who doesn't know: non trivial destructors are
really useful in gfm because it wraps some C libraries, and
cleaning up C allocated resources is usually important. Proper
execution of gfm's close() for every class would be ideal.
Sounds like an exact same problem I have run into recently: class
wrappers around HDF5 C library need to do something not @nogc in
a destructor and also have to call the C-level releasing
functions. Can't do that in a destructor since then you get the
invalidMemoryOperationError; can't make classes structs and use
refcounted since there's an implied type hierarchy which becomes
a mess with alias this... the only way is to put that in close()
and then not forget to call it manually.
Wish there was a standardized way of running non-@nogc user code
before the dtor actually runs (and anytime after it's known to be
guaranteed to run).
