From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-17158-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 19294 invoked by alias); 11 Apr 2002 18:46:04 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 19280 invoked by uid 71); 11 Apr 2002 18:46:03 -0000
Date: Thu, 11 Apr 2002 11:46:00 -0000
Message-ID: <20020411184603.19279.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: "Boehm, Hans" <hans_boehm@hp.com>
Subject: RE: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu
	res with -m64
Reply-To: "Boehm, Hans" <hans_boehm@hp.com>
X-SW-Source: 2002-04/txt/msg00621.txt.bz2
List-Id: <gcc-prs.sourceware.org>

The following reply was made to PR java/6092; it has been noted by GNATS.

From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'tromey@redhat.com'" <tromey@redhat.com>,
        "Kaveh R. Ghazi"
	 <ghazi@caip.rutgers.edu>
Cc: gcc-gnats@gcc.gnu.org, "Boehm, Hans" <hans_boehm@hp.com>
Subject: RE: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu
	res with -m64
Date: Thu, 11 Apr 2002 11:28:17 -0700

 Tom -
 
 That line in GC_stopped_mark calls GC_mark_some.  Thus I would conclude that
 this version of gdb is only partially functional, and it actually dies
 somewhere in GC_mark_some().
 
 A possible cause of that is confusion about where the roots are.  If you can
 check GC_stackbottom, check that the collector and libgcj configuration
 agree on threads, get GC_dump() output, and check the root locations against
 the nm output that might identify something.  Otherwise we need better debug
 information.
 
 Hans
 
 > -----Original Message-----
 > From: Tom Tromey [mailto:tromey@redhat.com]
 > 
 > I found a gdb here that seems to know how to debug on this machine.
 > It gives me the appended stack trace.
 > 
 > Hans, any clues you can give me on debugging this would be helpful.
 > 
 > Tom
 > 
 > 
 > (gdb) bt
 > #0  0xfffffeab7ed6fd50 in ?? ()
 > #1  0xffffffff7ed68f20 in GC_stopped_mark (
 >     stop_func=0xffffffff7ed68598 <GC_never_stop_func>)
 >     at ../../../../gcc/boehm-gc/alloc.c:489
 > #2  0xffffffff7ed68b88 in GC_try_to_collect_inner (
 >     stop_func=0xffffffff7ed68598 <GC_never_stop_func>)
 >     at ../../../../gcc/boehm-gc/alloc.c:350
 > #3  0xffffffff7ed72de0 in GC_init_inner ()
 >     at ../../../../gcc/boehm-gc/misc.c:673
 > #4  0xffffffff7ed72a60 in GC_init () at 
 > ../../../../gcc/boehm-gc/misc.c:455
 > #5  0xffffffff7ed6cce4 in GC_init_gcj_malloc (mp_index=32752, 
 >     mp=0xffffffff7ed655e4) at ../../../../gcc/boehm-gc/gcj_mlc.c:62
 > #6  0xffffffff7ed6636c in _Jv_InitGC() ()
 >     at ../../../../gcc/libjava/boehm.cc:465
 > #7  0xffffffff7ebe6520 in _Jv_CreateJavaVM(void*) ()
 >     at ../../../../gcc/libjava/prims.cc:892
 > #8  0xffffffff7ebe69b0 in _Jv_RunMain(java::lang::Class*, 
 > char const*, int, char const**, bool) (klass=0x100102518, 
 > name=0x0, argc=1, argv=0xffffffff7ffff718, 
 >     is_jar=false) at ../../../../gcc/libjava/prims.cc:982
 > #9  0x100001820 in main ()
 >