GC allocation issue

[Etienne]

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