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:


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

<TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libdruntime/gc/proxy.d:196

const(TypeInfo)) (sz=3D8, ba=3D0, ti=3D0x714050 <TypeInfo_PS2rt3aaA4Impl.in=
it$>)
at ../../../../dev/libphobos/libdruntime/core/memory.d:368

<TypeInfo_PS2rt3aaA4Impl.init$>) at
../../../../dev/libphobos/libdruntime/rt/lifetime.d:1096

<ClassInfo for core.thread.Thread>, valuesize=3D8, pkey=3D0x7fffffffd598) a=
t
../../../../dev/libphobos/libdruntime/rt/aaA.d:172

(this=3D0x7ffff7ed2080, dg=3D...) at
../../../../dev/libphobos/libdruntime/core/thread.d:3318

../../../../dev/libphobos/libdruntime/core/sync/mutex.d:262

e0
<ModuleInfo for core.sync.mutex>) at
../../../../dev/libphobos/libdruntime/core/runtime.d:448

0,
m=3D0x71a9e0 <ModuleInfo for core.sync.mutex>) at
../../../../dev/libphobos/libdruntime/object.d:1771

int(immutable(object.ModuleInfo*)) delegate) (dg=3D...) at
../../../../dev/libphobos/libdruntime/rt/minfo.d:287

int(object.ModuleInfo*) delegate) (dg=3D...) at
../../../../dev/libphobos/libdruntime/object.d:1770

../../../../dev/libphobos/libdruntime/core/runtime.d:438

../../../../dev/libphobos/libdruntime/rt/dmain2.d:428

int(char[][]) function*).tryExec(scope void() delegate)
(this=3D0x7fffffffdbe0, dg=3D...) at
../../../../dev/libphobos/libdruntime/rt/dmain2.d:40
4

mainFunc=3D0x402a60 <D main>) at
../../../../dev/libphobos/libdruntime/rt/dmain2.d:437

=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


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