[Gc] Re: Problem with libgc under Solaris 10 x86 (fwd)

Boehm, Hans hans.boehm at hp.com
Tue Mar 22 15:20:42 PST 2005


We know pretty much what's going on here.  It fails a very specific test
that verifies that objects pointed to by function arguments are not
reallocated.
In this case, they are.  This means the collector is not tracing from
some of the
locations that are used to hold argument values.

Based on off-list information, I think it's dying in the same lwp that
initiated the GC.

I think the problem is either the register marking code, or the
code for marking from thread stacks.  The former is suspect, because the
compiler may well be storing pointers in registers that didn't exist on
the architecture when the Solaris/X86 code was written.  The latter is
suspect because Solaris currently uses nonstandard support code for
pthreads,
and that has been tested mostly on SPARC.

Did you try running this without thread support?  Does it still break?

The other interesting experiment is to try it with
-DUSE_GENERIC_PUSH_REGS.

I would try both experiments by building with Makefile.direct, but the
former should also work with configure --disable-threads.

I assume you are not using gcc?  Otherwise USE_GENERIC_PUSH_REGS is
probably already defined implicitly.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ben Hutchings
> Sent: Monday, March 14, 2005 6:25 AM
> To: Apostolos Syropoulos
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] Re: Problem with libgc under Solaris 10 x86 (fwd)
> 
> 
> Apostolos Syropoulos wrote:
> <snip>
> > Indeed. Here is the debugger's output:
> > 
> > apostolo at ocean1>> ./test
> > Apparently failed to mark form some function arguments. Perhaps 
> > GC_push_regs was configured incorrectly? Test failed
> > Abort (core dumped)
> > apostolo at ocean1>> adb test core
> > core file = core -- program ``test'' on platform i86pc
> > SIGABRT: Abort
> > $C
> > 08046f04 libc.so.1`_lwp_kill+0x15(1, 6)
> > 08046f1c libc.so.1`raise+0x1f(6)
> > 08046f68 libc.so.1`abort+0xcd(8065504, 0, 8047138, 8057d1c, 
> 80669e7, 0)
> > 08046f78 GC_err_puts(80669e7, 0, 0, 80b3fc0, 80b3fc0, 80b3fd0)
> > 08047138 uniq+0x94(80b3fc0, 80b3fd0, 80b3fe0, 80b3ff0, 
> 80b3fb0, 80b3fc0)
> > 080471a8 run_one_test+0x406(80471d0, d27de044, d27a0315, 
> d2720841, 29, 4)
> > 080471d8 main+0x89(1, 8047210, 8047218)
> > 08047204 _start+0x5d(1, 8047358, 0, 804735f, 80473c5, 80473da)
> > $Q
> > 
> >>From the above I deduce that the problem is light-weight processes 
> >>(a.k.a.
> > solaris threads). Any comments anr/or suggestions?
> <snip>
> 
> Don't jump to conclusions before reading the *whole* stack 
> trace and the 
> source for the functions involved (where available).  test.c 
> deliberately calls abort if a test fails.
> 
> Ben.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list