Tracing down core.exception.InvalidMemoryOperationError

[fra via Digitalmars-d-learn]

On Monday, 28 July 2014 at 22:13:56 UTC, Joakim wrote:
> On Monday, 28 July 2014 at 13:31:08 UTC, Martin Drasar via 
> Digitalmars-d-learn wrote:
>> On 28.7.2014 14:09, Joakim via Digitalmars-d-learn wrote:
>>> More broadly speaking, it is thrown whenever certain memory 
>>> operations
>>> are attempted while the GC is running, 6 in all, as you can 
>>> see here:
>>> 
>>> https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L458
>>> 
>>> 
>>> I believe I stuck in printfs till I found out which one was 
>>> run before
>>> the error was thrown, and then traced that back with more 
>>> printfs to
>>> where it was getting called.  I didn't have a debugger 
>>> available, you
>>> may be able to trace faster with one.
>>
>> Hi,
>>
>> thanks for the tip. I have a debugger at hand and I am would 
>> prefer to
>> use it. However, I don't really know where and how to start. I 
>> would
>> like to break at core/exception.d when 
>> onInvalidMemoryOperationError is
>> called, but I am not sure how to build druntime with debug 
>> information.
>> There does not seem to be some flag in the makefile like for 
>> dmd.
>>
>> Is there some document describing how to do this?
>
> It's not in the makefile; I simply added the -g or -gc flag 
> where it compiled and then the debug symbols showed up in the 
> debugger.
>  You may also want to experiment with the -debug flag, which 
> will turn on various kinds of log output depending on which 
> module and flag you use it with.

I can tell you it is the logger, for sure. I have had similar 
problems in the past because I was trying to print a string in a 
destructor, and even just using the string concatenation is 
enough for an allocation to happen and for the exception to ruin 
everything. As a bonus, the exception is thrown from another 
thread :P
In fact, now that we have @nogc I really think we could use *at 
least a warning* if the compiler determines that allocation might 
happen inside a destructor...
(btw: a debug strategy might be: fire up dmd beta 2.066, add 
@nogc at all destructors and see where the compiler complains)