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