Re: Problems with compilation on Trisquel 5.5

[Sjoerd van Leent]

Answering myself,

I finally found the problem. Somehow one of the files during unpacking
the tarball of BDW got corrupted, which was indeed this particular
method. Compared a new unpacked version and they where slightly
different and enough to get the system go freaky.

Regards,
Sjoerd

2012/5/10 Sjoerd van Leent <address@hidden>:

>
> 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