On 2014-03-21 10:34 AM, Etienne wrote:
It crashes when sz approaches 0x180000, it looks like (my best guess)
the resized array doesn't get allocated but the GC still tries to scan it.
Ok I found it in the manual implementation of a malloc-based HashMap.
The right way to debug this was, sadly, to add a lot of printf and a few
asserts in druntime, and redirecting the stdout to a file from the shell
(./exe > logoutput.txt). The druntime win32.mak doesn't have a debug
build so I had to add -debug -g in there to add symbols and make the
sources show up instead of the disassembly in VisualD.
In this case, the logs showed gc's mark() was failing on wide ranges, so
I added an assert in addRange to make it throw when that range was
added, and it finally gave me the call stack of the culprit.
The issue was that a malloc range was (maybe) not being properly
initialized before being added to the GC.
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/utils/hashmap.d#L221
https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/utils/memory.d#L153
In this case, ptr isn't null and the range existed, but there's still an
access violation from the GC for some reason. I'll keep searching for
the root cause but it doesn't seem to be a GC issue anymore; though the
debugging procedure could use some documentation.
Thanks
