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