• crimaniak (12/12) Jul 10 2017 Hi!
• Joakim (6/18) Jul 15 2017 See the wiki page about this:
• crimaniak (27/34) Jul 16 2017 Yes, I found it already and make documentation proposition about

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.

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/

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.