Thread overview | |||||
---|---|---|---|---|---|
|
December 01, 2015 GC buckets in 2.067 | ||||
---|---|---|---|---|
| ||||
Attachments:
| 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 Re: GC buckets in 2.067 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 Re: GC buckets in 2.067 | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger Attachments:
| 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 |
Copyright © 1999-2021 by the D Language Foundation