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

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

Sjoerd van Leent

reply via email to

[Prev in Thread] Current Thread [Next in Thread]