www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC buckets in 2.067

reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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=3D..., size=3D8, bits=3D0, alloc_size=3D0x7fffffffd4=
28,
ti=3D0x714050 <TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libd
runtime/gc/gc.d:459
#2  0x00000000004c5948 in gc_qalloc (sz=3D8, ba=3D0, ti=3D0x714050
<TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libdruntime/gc/proxy.d:196
#3  0x00000000004450de in core.memory.GC.qalloc(ulong, uint,
const(TypeInfo)) (sz=3D8, ba=3D0, ti=3D0x714050 <TypeInfo_PS2rt3aaA4Impl.in=
it$>)
at ../../../../dev/libphobos/libdruntime/core/memory.d:368
#4  0x0000000000420e31 in _d_newitemT (_ti=3D0x714050
<TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libdruntime/rt/lifetime.d:1096
#5  0x0000000000411f6c in _aaGetX (aa=3D0x7ffff7ed2090, keyti=3D0x7191a0
<ClassInfo for core.thread.Thread>, valuesize=3D8, pkey=3D0x7fffffffd598) a=
t
../../../../dev/libphobos/libdruntime/rt/aaA.d:172
#6  0x0000000000449f6d in core.thread.ThreadGroup.create(void() delegate)
(this=3D0x7ffff7ed2080, dg=3D...) 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=3D0x7fffffffd790, m=3D0x71a9=
e0
<ModuleInfo for core.sync.mutex>) at
../../../../dev/libphobos/libdruntime/core/runtime.d:448
#9  0x0000000000407c1e in object.ModuleInfo.__lambda2 (this=3D0x7fffffffd75=
0,
m=3D0x71a9e0 <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=3D...) at
../../../../dev/libphobos/libdruntime/rt/minfo.d:287
#11 0x0000000000407beb in object.ModuleInfo.opApply(scope
int(object.ModuleInfo*) delegate) (dg=3D...) at
../../../../dev/libphobos/libdruntime/object.d:1770
#12 0x00000000004457fa in runModuleUnitTests () at
../../../../dev/libphobos/libdruntime/core/runtime.d:438
#13 0x000000000041ab36 in runAll (this=3D0x7fffffffdbe0) 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=3D0x7fffffffdbe0, dg=3D...) at
../../../../dev/libphobos/libdruntime/rt/dmain2.d:40
4
#15 0x000000000041aa2b in _d_run_main (argc=3D1, argv=3D0x7fffffffdd68,
mainFunc=3D0x402a60 <D main>) at
../../../../dev/libphobos/libdruntime/rt/dmain2.d:437
#16 0x00007ffff6ee6a40 in __libc_start_main (main=3D0x402910 <main>, argc=
=3D1,
argv=3D0x7fffffffdd68, init=3D<optimised out>, fini=3D<optimised out>,
rtld_fini=3D<optimised out>, stack_end=3D0x7fffffffdd58) at libc-start.c:28=
9
#17 0x0000000000402969 in _start ()

In gc.d
---
 459=E2=94=9C>            memset(p + size, 0, *alloc_size - size);

p =3D (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=E2=94=82         // Return next item from free list
1797=E2=94=9C>        bucket[bin] =3D (cast(List*)p).next;

Where:

*(cast(List*)p) =3D {next =3D 0x4c9fad <__gdc_exception_cleanup>, pool =3D =
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?
Dec 01 2015
parent reply David Nadlinger <code klickverbot.at> writes:
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
Dec 01 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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 =E2=80=93 are you sure that your GC root ranges (.data/stacks/TLS) are se=
t
 correctly?

  =E2=80=94 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=E2=94=82 for (List *list =3D bucket[n]; list; list =3D lis= t.next) 2458=E2=94=82 { 2459=E2=94=82 pool =3D list.pool; 2460=E2=94=9C> assert(pool); 2461=E2=94=82 pool.freebits.set(cast(size_t)(cast(byte*)lis= t - pool.baseAddr) / 16); 2462=E2=94=82 } 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
Dec 01 2015