GC buckets in 2.067

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 4 16:33:22 PST 2015


On 5 December 2015 at 00:40, Iain Buclaw <ibuclaw at gdcproject.org> wrote:

> On 4 December 2015 at 21:52, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
>
>> On 1 December 2015 at 09:46, Iain Buclaw <ibuclaw at gdcproject.org> wrote:
>>
>>> 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
>>>
>>
>> DMD dropped calling this function in favour for _aaGetY().
>>
>> Maybe I'm chasing a dead end, but maybe, *maybe* something changed and
>> _aaGetX was not updated parallel?
>>
>> Iain.
>>
>
> Well, reverting all of druntime 2.067 (minus the bits that produce new
> errors) and I don't hit this error.
>
> At least I have a (rather large) starting point to bisect down. :-)
>
>
Squashed down to a 1600 line diff of rt.lifetime, everything else has been
applied and passes the unittests just fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20151205/2d73095c/attachment-0001.html>


More information about the Digitalmars-d mailing list