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)
