Re: Tracing down core.exception.InvalidMemoryOperationError
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.
Re: Tracing down core.exception.InvalidMemoryOperationError
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
Re: Tracing down core.exception.InvalidMemoryOperationError
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.
Re: Tracing down core.exception.InvalidMemoryOperationError
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)
