Hi!

I have vibe.d application and long-standing error in it.
For the current moment, I have logs for stdout, stderr, and additional log to write exceptions I catch. This error gives me only the short line in stderr log:

core.exception.InvalidMemoryOperationError@src/core/exception.d(696): Invalid memory operation
----------------

Also, I use registerMemoryErrorHandler(); (see http://vibed.org/docs#handling-segmentation-faults )

What else can I do to have the stack trace for this error?

I can't debug it because I don't have it on my developer's machine.

On Tuesday, 11 July 2017 at 01:34:08 UTC, crimaniak wrote:
> Hi!
>
> I have vibe.d application and long-standing error in it.
> For the current moment, I have logs for stdout, stderr, and additional log to write exceptions I catch. This error gives me only the short line in stderr log:
>
> core.exception.InvalidMemoryOperationError@src/core/exception.d(696): Invalid memory operation
> ----------------
>
> Also, I use registerMemoryErrorHandler(); (see http://vibed.org/docs#handling-segmentation-faults )
>
> What else can I do to have the stack trace for this error?
>
> I can't debug it because I don't have it on my developer's machine.

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/

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.