Thread overview
Tracing down core.exception.InvalidMemoryOperationError
Jul 28, 2014
Martin Drasar
Jul 28, 2014
Joakim
Jul 28, 2014
Martin Drasar
Jul 28, 2014
Joakim
Jul 29, 2014
fra
July 28, 2014
Hi,

at the end of my program it throws InvalidMemoryOperationError. Looking at the documentation and past forum questions I learned that it is probably because of allocations in destructors. However, I have no such thing in my code (at least not intentionally). I am suspecting the std.logger package, because it throwed on me a memory error on occasions. But regardless of the source, I would like to trace it and deal with it. But I do not have much of an idea where to start. Could you give me an advice?

Thanks,
Drasha
July 28, 2014
On Monday, 28 July 2014 at 09:38:35 UTC, Martin Drasar via Digitalmars-d-learn wrote:
> Hi,
>
> at the end of my program it throws InvalidMemoryOperationError. Looking
> at the documentation and past forum questions I learned that it is
> probably because of allocations in destructors. However, I have no such
> thing in my code (at least not intentionally). I am suspecting the
> std.logger package, because it throwed on me a memory error on
> occasions. But regardless of the source, I would like to trace it and
> deal with it. But I do not have much of an idea where to start. Could
> you give me an advice?

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.
July 28, 2014
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?

Thanks,
Drasha
July 28, 2014
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.
July 29, 2014
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)