Issues with debugging GC-related crashes #2

[Matthias Klumpp]

On Thursday, 19 April 2018 at 08:30:45 UTC, Kagamin wrote:
> On Wednesday, 18 April 2018 at 22:24:13 UTC, Matthias Klumpp 
> wrote:
>> 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...)
>
> If big LMDB mapping causes a problem, try a test like this:
> ---
> import core.memory;
> void testLMDB()
> {
>     //how do you use it?
> }
> void test1()
> {
>     void*[][] a;
>     foreach(i;0..100000)a~=new void*[10000];
>     void*[][] b;
>     foreach(i;0..100000)b~=new void*[10000];
>     b=null;
>     GC.collect();
>
>     testLMDB();
>
>     GC.collect();
>     foreach(i;0..100000)a~=new void*[10000];
>     foreach(i;0..100000)b~=new void*[10000];
>     b=null;
>     GC.collect();
> }
> ---

I tried something similar, with no effect.
Something that maybe is relevant though: I occasionally get the 
following SIGABRT crash in the tool on machines which have the 
SIGSEGV crash:
```
Thread 53 "appstream-gener" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fdfe98d4700 (LWP 7326)]
0x00007ffff5040428 in __GI_raise (sig=sig at entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or 
directory.
(gdb) bt
#0  0x00007ffff5040428 in __GI_raise (sig=sig at entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff504202a in __GI_abort () at abort.c:89
#2  0x0000000000780ae0 in core.thread.Fiber.allocStack(ulong, 
ulong) (this=0x7fde0758a680, guardPageSize=4096, sz=20480) at 
src/core/thread.d:4606
#3  0x00000000007807fc in 
_D4core6thread5Fiber6__ctorMFNbDFZvmmZCQBlQBjQBf 
(this=0x7fde0758a680, guardPageSize=4096, sz=16384, dg=...)
     at src/core/thread.d:4134
#4  0x00000000006f9b31 in 
_D3std11concurrency__T9GeneratorTAyaZQp6__ctorMFDFZvZCQCaQBz__TQBpTQBiZQBx (this=0x7fde0758a680, dg=...)
     at 
/home/ubuntu/dtc/dmd/generated/linux/debug/64/../../../../../druntime/import/core/thread.d:4126
#5  0x00000000006e9467 in 
_D5asgen8handlers11iconhandler5Theme21matchingIconFilenamesMFAyaSQCl5utils9ImageSizebZC3std11concurrency__T9GeneratorTQCfZQp (this=0x7fdea2747800, relaxedScalingRules=true, size=..., iname=...) at ../src/asgen/handlers/iconhandler.d:196
#6  0x00000000006ea75a in 
_D5asgen8handlers11iconhandler11IconHandler21possibleIconFilenamesMFAyaSQCs5utils9ImageSizebZ9__lambda4MFZv (this=0x7fde0752bd00)
     at ../src/asgen/handlers/iconhandler.d:392
#7  0x000000000082fdfa in core.thread.Fiber.run() 
(this=0x7fde07528580) at src/core/thread.d:4436
#8  0x000000000082fd5d in fiber_entryPoint () at 
src/core/thread.d:3665
#9  0x0000000000000000 in  ()
```

This is in the constructor of a std.concurrency.Generator:
auto gen = new Generator!string (...)

I am not sure what to make of this yet though... This goes into 
DRuntime territory that I actually hoped to never have to deal 
with as much as I apparently need to now.