[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with compilation on Trisquel 5.5
From: |
Sjoerd van Leent |
Subject: |
Re: Problems with compilation on Trisquel 5.5 |
Date: |
Thu, 10 May 2012 21:31:18 +0200 |
Met vriendelijke groet,
Sjoerd
2012/5/4 <address@hidden>:
> Message: 1
> Date: Thu, 03 May 2012 21:47:28 +0200
> From: address@hidden (Ludovic =?iso-8859-1?Q?Court=E8s?=)
> To: Andy Wingo <address@hidden>
> Cc: address@hidden
> Subject: Re: Problems with compilation on Trisquel 5.5
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=utf-8
>
> Andy Wingo <address@hidden> skribis:
>
>> On Wed 02 May 2012 23:15, address@hidden (Ludovic Court?s) writes:
>>
>>> Andy Wingo <address@hidden> skribis:
>>>
>>>> Some versions of libgc do produce one SIGSEGV at startup, when
>>>> determining certain aspects of the process's memory layout. Just FYI :)
>>>
>>> Woow. :-) Do you know which versions/arches are affected?
>>
>> I don't recall. It's an expected SIGSEGV, not an erroneous one.
>
> Aaah, OK, makes sense.
>
> Thanks,
> Ludo?.
To shed some light on this topic, I got into the sources of the BDW gc
7.1 implementation What appears to go wrong is this line in malloc.c:
line 122: GC_ASSERT(lg != 0);
Somehow, the value given in GC_generic_malloc_inner, on my system,
gets the GC_size_map to fetch a zero from that particular array. This
means two things:
Somehow, the GC_size_map is not big enough in the first place and
GC_extend_size_map goes bananas.
I have no clue whether this is a GC issue or a Guile issue...
Regards,
Sjoerd van Leent