Thread overview
GC buckets in 2.067
Dec 01, 2015
Iain Buclaw
Dec 01, 2015
David Nadlinger
Dec 01, 2015
Iain Buclaw
December 01, 2015
When running the unittest program for druntime.

---
Program received signal SIGSEGV, Segmentation fault. __memset_avx2 () at ../sysdeps/x86_64/multiarch/memset-avx2.S:101

backtrace:
#0  __memset_avx2 () at ../sysdeps/x86_64/multiarch/memset-avx2.S:101
#1  0x00000000004d45a0 in gc.gc.GC.malloc(ulong, uint, ulong*,
const(TypeInfo)) (this=..., size=8, bits=0, alloc_size=0x7fffffffd428,
ti=0x714050 <TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libd
runtime/gc/gc.d:459
#2  0x00000000004c5948 in gc_qalloc (sz=8, ba=0, ti=0x714050
<TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libdruntime/gc/proxy.d:196
#3  0x00000000004450de in core.memory.GC.qalloc(ulong, uint,
const(TypeInfo)) (sz=8, ba=0, ti=0x714050 <TypeInfo_PS2rt3aaA4Impl.init$>)
at ../../../../dev/libphobos/libdruntime/core/memory.d:368
#4  0x0000000000420e31 in _d_newitemT (_ti=0x714050
<TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libdruntime/rt/lifetime.d:1096
#5  0x0000000000411f6c in _aaGetX (aa=0x7ffff7ed2090, keyti=0x7191a0
<ClassInfo for core.thread.Thread>, valuesize=8, pkey=0x7fffffffd598) at
../../../../dev/libphobos/libdruntime/rt/aaA.d:172
#6  0x0000000000449f6d in core.thread.ThreadGroup.create(void() delegate)
(this=0x7ffff7ed2080, dg=...) at
../../../../dev/libphobos/libdruntime/core/thread.d:3318
#7  0x00000000004c28ed in core.sync.mutex.__unittestL241_1() () at
../../../../dev/libphobos/libdruntime/core/sync/mutex.d:262
#8  0x0000000000445a7b in __foreachbody3 (this=0x7fffffffd790, m=0x71a9e0
<ModuleInfo for core.sync.mutex>) at
../../../../dev/libphobos/libdruntime/core/runtime.d:448
#9  0x0000000000407c1e in object.ModuleInfo.__lambda2 (this=0x7fffffffd750,
m=0x71a9e0 <ModuleInfo for core.sync.mutex>) at
../../../../dev/libphobos/libdruntime/object.d:1771
#10 0x000000000041c58d in rt.minfo.moduleinfos_apply(scope
int(immutable(object.ModuleInfo*)) delegate) (dg=...) at
../../../../dev/libphobos/libdruntime/rt/minfo.d:287
#11 0x0000000000407beb in object.ModuleInfo.opApply(scope
int(object.ModuleInfo*) delegate) (dg=...) at
../../../../dev/libphobos/libdruntime/object.d:1770
#12 0x00000000004457fa in runModuleUnitTests () at
../../../../dev/libphobos/libdruntime/core/runtime.d:438
#13 0x000000000041ab36 in runAll (this=0x7fffffffdbe0) at
../../../../dev/libphobos/libdruntime/rt/dmain2.d:428
#14 0x000000000041aad2 in rt.dmain2._d_run_main(int, char**, extern(C)
int(char[][]) function*).tryExec(scope void() delegate)
(this=0x7fffffffdbe0, dg=...) at
../../../../dev/libphobos/libdruntime/rt/dmain2.d:40
4
#15 0x000000000041aa2b in _d_run_main (argc=1, argv=0x7fffffffdd68,
mainFunc=0x402a60 <D main>) at
../../../../dev/libphobos/libdruntime/rt/dmain2.d:437
#16 0x00007ffff6ee6a40 in __libc_start_main (main=0x402910 <main>, argc=1,
argv=0x7fffffffdd68, init=<optimised out>, fini=<optimised out>,
rtld_fini=<optimised out>, stack_end=0x7fffffffdd58) at libc-start.c:289
#17 0x0000000000402969 in _start ()

In gc.d
---
 459├>            memset(p + size, 0, *alloc_size - size);

p = (void *) 0x4c9fad <__gdc_exception_cleanup>
---

So the GC is trying to run memset on the address of a function.

It's caused by this line:

1796│         // Return next item from free list
1797├>        bucket[bin] = (cast(List*)p).next;

Where:

*(cast(List*)p) = {next = 0x4c9fad <__gdc_exception_cleanup>, pool = 0x0}


Not sure what is going on, but it seems to happen after allocating memory a couple dozen or so times.

David, did you get anything like this when moving to 2.067?


December 01, 2015
On Tuesday, 1 December 2015 at 08:47:03 UTC, Iain Buclaw wrote:
> David, did you get anything like this when moving to 2.067?

It has been almost a year now, but I don't remember anything like that – are you sure that your GC root ranges (.data/stacks/TLS) are set correctly?

 — David
December 01, 2015
On 1 December 2015 at 16:55, David Nadlinger via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Tuesday, 1 December 2015 at 08:47:03 UTC, Iain Buclaw wrote:
>
>> David, did you get anything like this when moving to 2.067?
>>
>
> It has been almost a year now, but I don't remember anything like that – are you sure that your GC root ranges (.data/stacks/TLS) are set correctly?
>
>  — David
>

Every update I make sure to keep the old _tlsstart/_tlsend implementation intact.  So it should be adding ranges as per 2.066.

I reverted the GC changes to 2.066 and recompiled.

Now I have a null pool pointer at:

2457│             for (List *list = bucket[n]; list; list = list.next)
2458│             {
2459│                 pool = list.pool;
2460├>                assert(pool);
2461│                 pool.freebits.set(cast(size_t)(cast(byte*)list -
pool.baseAddr) / 16);
2462│             }


Maybe there's a codegen change that I haven't picked up.  This is likely as if feels like 70% of the changes in dmd are unwanted noise.

Iain