Met vriendelijke groet, Sjoerd
2012/5/4 <[email protected]>: > Message: 1 > Date: Thu, 03 May 2012 21:47:28 +0200 > From: [email protected] (Ludovic =?iso-8859-1?Q?Court=E8s?=) > To: Andy Wingo <[email protected]> > Cc: [email protected] > Subject: Re: Problems with compilation on Trisquel 5.5 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > Andy Wingo <[email protected]> skribis: > >> On Wed 02 May 2012 23:15, [email protected] (Ludovic Court?s) writes: >> >>> Andy Wingo <[email protected]> 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
