Issues with debugging GC-related crashes #2

[Johannes Pfau]

Am Thu, 19 Apr 2018 07:04:14 +0000 schrieb Johannes Pfau:

> Am Thu, 19 Apr 2018 06:33:27 +0000 schrieb Johannes Pfau:
> 
> 
>> Generally if you produced a crash in gdb it should be reproducible if
>> you restart the program in gdb. So once you have a crash, you should be
>> able to restart the program and look at the _dso_registry and see the
>> same addresses somewhere. If you then think you see memory corruption
>> somewhere you could also use read or write watchpoints.
>> 
>> But just to be sure: you're not adding any GC ranges manually, right?
>> You could also try to compare the GC range to the address range layout
>> in /proc/$PID/maps .
> 
> Of course, if this is a GC pool / heap range adding breakpoints in the
> sections code won't be useful. Then I'd try to add a write watchpoint on
> pooltable.minAddr / maxAddr, restart the programm in gdb and see where /
> why the values are set.

Having a quick look at https://github.com/ldc-developers/druntime/blob/
ldc/src/gc/pooltable.d: The GC seems to allocate multiple pools using 
malloc, but only keeps track of one minimum/maximum address for all 
pools. Now if there's some other memory area malloced in between these 
pools, you will end up with a huge memory block. When this will get 
scanned and if any of the memory in-between the GC pools is protected, 
you might see the GC crash. However, I don't really know anything about 
the GC code, so some GC expert would have to confirm this.



-- 
Johannes