[Ecls-list] RE: [Gc] Boehm-Weiser GC on OpenBSD

[Boehm, Hans]

This is a common place for the collector to fail in the event of
configuration problems.  It found an entry on the mark stack
describing a memory region that doesn't exist.  Typically that's
because it thinks there's a stack or static data in a memory
region that is in fact unmapped, or at least not readable.

You want to find out what the value of "limit" is when it fails,
and compare that to the output of GC_dump() called at about that
point.  The value of GC_stackbottom and the current stack pointer
are probably also of interest.

I can't test on OpenBSD, so it's quite possible for that port to
get behind.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Juan Jose 
> Garcia Ripoll
> Sent: Tuesday, March 15, 2005 7:48 AM
> To: gc at napali.hpl.hp.com
> Cc: ecls-list at lists.sourceforge.net
> Subject: [Gc] Boehm-Weiser GC on OpenBSD
> 
> 
> [Cross-posted to the ECL mailing list]
> 
> Hi,
> 
> my name is Juanjo and I am the maintainer of a Common-Lisp 
> implementation called ECL (http://ecls.sf.net). For several years we 
> have been using the Boehm-Weiser garbage collector successfully on 
> several platforms (Linux x86/Alpha/PPC, Solaris/Sparc, 
> OSX/PPC, Windows...)
> 
> However, our port to the OpenBSD platform fails already at 
> initialization time, when we call GC_init(). More precisely, 
> as you'll 
> see below, the GC library fails when doing the first garbage 
> collection 
> in GC_init(). I could set GC_dont_precollect to 1, but then the 
> collector quickly runs out of memory.
> 
> We are using v6.4 of the garbage collector, the library is configured 
> with "--disable-shared --disable-threads" and I have tried both using 
> GC_no_dls=1 and GC_no_dls=0 (Actually the former is preferred 
> because we 
> our interpreter garbage collects DLLs).
> 
> Any hints?
> 
> TIA,
> 
> Juanjo
> 
> --------------
> 
> Excerpt from GDB's output when running our interpreter. If 
> somebody is 
> interested, he can grab the latest code from CVS 
> (http://sourceforge.net/cvs/?group_id=30035), do "./configure" and 
> "make". The process will break while running "ecl_min", which is a 
> minimal version of our common-lisp environment, used for 
> compiling and 
> bootstrapping the rest:
> 
> x86-openbsd1:~/ecls/build$ uname -a
> OpenBSD x86-openbsd1.cf.sourceforge.net 3.4 GENERIC#18 i386
> 
> x86-openbsd1:~/ecls/build$ gdb ecl_min
> GNU gdb 4.16.1
> Copyright 1996 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public 
> License, and you are welcome to change it and/or distribute 
> copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show 
> warranty" for details. This GDB was configured as 
> "i386-unknown-openbsd3.4"...
> 
> (gdb) run
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x1c05536d in GC_find_limit (p=0x3c017640 "\230\002¿Ï", up=0)
>     at /home/users/j/jj/jjgarcia/ecls/src/gc/os_dep.c:811
> 811                     GC_noop1((word)(*result));
> (gdb) cont
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x1c05536d in GC_find_limit (
>     p=0xcfbf00fc "´û\001< 
> \001¿Ï\236C\005\034°`\001<0z\001<D\002¿Ï", up=1)
>     at /home/users/j/jj/jjgarcia/ecls/src/gc/os_dep.c:811
> 811                     GC_noop1((word)(*result));
> (gdb) cont
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x1c052122 in GC_mark_from (mark_stack_top=0x3c0280a8, 
> mark_stack=0x3c0280a8,
>     mark_stack_limit=0x3c0300a8)
>     at /home/users/j/jj/jjgarcia/ecls/src/gc/mark.c:759
> 759               deferred = *limit;
> (gdb) cont
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>