www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Tracing down core.exception.InvalidMemoryOperationError

reply Martin Drasar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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
Jul 28 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
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.
Jul 28 2014
parent reply Martin Drasar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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
Jul 28 2014
parent reply "Joakim" <dlang joakim.airpost.net> writes:
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.
Jul 28 2014
parent "fra" <a b.it> writes:
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)
Jul 28 2014