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 <[email protected]>: > > 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
