www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - stacktrace for InvalidMemoryOperationError

reply crimaniak <crimaniak gmail.com> writes:
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.
Jul 10
parent reply Joakim <dlang joakim.fea.st> writes:
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/
Jul 15
parent crimaniak <crimaniak gmail.com> writes:
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.
Jul 16