Issues with debugging GC-related crashes #2

[Johannes Pfau]

Am Wed, 18 Apr 2018 22:24:13 +0000 schrieb Matthias Klumpp:

> On Wednesday, 18 April 2018 at 22:12:12 UTC, kinke wrote:
>> On Wednesday, 18 April 2018 at 20:36:03 UTC, Johannes Pfau wrote:
>>> Actually this sounds very familiar:
>>> https://github.com/D-Programming-GDC/GDC/pull/236
>>
>> Interesting, but I don't think it applies here. Both start and end
>> addresses are 16-bytes aligned, and both cannot be accessed according
>> to the stack trace (`pbot=0x7fcf4d721010 <error: Cannot access memory
>> at address 0x7fcf4d721010>, ptop=0x7fcf4e321010 <error: Cannot access
>> memory at address 0x7fcf4e321010>`). That's quite interesting too:
>> `memSize = 209153867776`. Don't know what exactly it is, but it's a
>> pretty large number (~194 GB).
> 
> size_t memSize = pooltable.maxAddr - minAddr;
> (https://github.com/ldc-developers/druntime/blob/ldc/src/gc/impl/
conservative/gc.d#L1982
> )
> That wouldn't make sense for a pool size...
> 
> The machine this is running on has 16G memory, at the time of the crash
> the software was using ~2.1G memory, with 130G virtual memory due to
> LMDB memory mapping (I wonder what happens if I reduce that...)

I see. Then I'd try to debug where the range originally comes from, try 
adding breakpoints in _d_dso_registry, registerGCRanges and similar 
functions here: https://github.com/dlang/druntime/blob/master/src/rt/
sections_elf_shared.d#L421

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 .



-- 
Johannes