On Saturday, 15 July 2017 at 18:14:13 UTC, Joakim wrote:
core.exception.InvalidMemoryOperationError@src/core/exception.d(696): Invalid
memory operation
...
See the wiki page about this:
https://wiki.dlang.org/InvalidMemoryOperationError
If you can't do all that, look for places you might be
allocating in a destructor. The recent GC allocation flag -vgc
might help:
https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
Yes, I found it already and make documentation proposition about
https://issues.dlang.org/show_bug.cgi?id=17642
Then it turned out that it was more difficult to avoid this
problem than to find the cause. Yes, I have a heavy cleanup in
the destructor and I can't definitely make this cleanup @nogc. So
first I tried to make problematic object instances RefCounted. In
my case, it means change ClientController[string] to
RefCounted!ClientController[string] and create an object by lib
interface, not by new. I have to change ClientController from
object to struct because automem can't work with the object. I
hunted all extra copies of these objects and kill them all, so
now I sure there are no copies except the main container. I tried
different libraries from std.typecons.RefCounted to automem. And
I fail to make it _really_ reference counted. It's not deleted
when I delete it from the container. Every time it's collected by
GC and application is dropped. So I decided that in the container
itself. Obviously, the associative array does not delete the
elements themselves on demand, but loses them and gives them to
the garbage collector.
I didn't find any map or multimap @nogc container so I make the
ugly solution: I move all destruction to method destructMe() and
in ~this() now is just assert(destructMeIsCalled). And now I have
to call manually destructMe() before object removing. It seems it
works. I'm wondering if there is a less ugly way to have the map
of reference counted objects.
