RE: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu res with -m64

RE: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu res with -m64

[Boehm, Hans]

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

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

 I just noticed that Linux/SPARC has a similar rule for DATASTART, but it's
 lightly different in the 64 bit case.  As a wild guess, I would try using
 the Linux rule for Solaris as well.  It seems to me that they are probably
 meant to be the same?
 
 Hans
 
 > -----Original Message-----
 > From: Boehm, Hans 
 > I would guess that (b) is the problem here.  It may be that 
 > the data segment in fact starts at a higher address than what 
 > the collector is assuming.  The collector currently assumes 
 > the same spacing between etext and the start of the data 
 > segment as with the 32 bit ABI.  I think this doesn't work 
 > well if the page size exceeds 64K, which may have been 
 > perceived as a problem by the designers of the 64 bit ABI.
 > 
 > If this doesn't lead to a diganosis of the problem, it would 
 > also be very helpful to extract the fault address somehow.  
 > If you can determine the faulting instruction and the 
 > corresponding register contents, that should be fairly easy.  
 > It wasn't clear to me whather gdb is sufficiently functional 
 > to do that.
 > 
 > Hans
 > 

RE: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu res with -m64

[Boehm, Hans]

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>,
        "Boehm, Hans"
	 <hans_boehm@hp.com>
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, gcc-gnats@gcc.gnu.org
Subject: RE: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu
	 	res with -m64
Date: Mon, 15 Apr 2002 16:42:33 -0700

 > From: Tom Tromey [mailto:tromey@redhat.com]
 > Hans> A possible cause of that is confusion about where the roots are.
 > Hans> If you can check GC_stackbottom, check that the collector and
 > Hans> libgcj configuration agree on threads, get GC_dump() output, and
 > Hans> check the root locations against the nm output that might
 > Hans> identify something.  Otherwise we need better debug information.
 > 
 > In order to reduce the number of variables a bit, I tried gctest.  I
 > got the same problem.  Here's some info.
 > 
 > (gdb) call GC_dump()
 > ***Static roots:
 > From 0x100106000 to 0x10012d8b8 
 > Total size: 161976
 > 
 > ***Heap sections:
 > Total heap size: 131072
 > Section 0 from 0x100178000 to 0x100198000 0/16 blacklisted
 > 
 > ***Free blocks:
 > Free list 16 (Total size 131072):
 > 	0x100178000 size 131072 not black listed
 > Total of 131072 bytes on free list
 > 
 > ***Blocks in use:
 > (kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, 
 > #_marks_set)
 > 
 > blocks = 0, bytes = 0
 > 
 I hadn't appreciated the fact that this was dying during initialization.
 That's further strong evidence that it in fact does have the root set wrong.
 Otherwise this looks plausible.
 > 
 > 
 > (gdb) p GC_stackbottom
 > $3 = 0xffffffff80000000 <Address 0xffffffff80000000 out of bounds>
 > 
 > I dug through the source a bit.  I think this machine doesn't define
 > USERLIMIT (a simple test program fails), so we must be using 
 > HEURISTIC2.
 > 
 I agree.  Can you print the stack pointer with gdb right after startup, and
 verify that it's just below that value?
 > 
 > When using nm what am I looking for?  I looked at one global,
 > GC_gc_no.  Its address falls into the range that GC_dump prints for
 > the static roots.  Should I do this comparison for all the globals?
 > 
 You want to get the symbols sorted in numeric order (nm -n on Linux; you may
 need nm -p | sort on Solaris).  I would then check that 
 
 a) It looks like all data and bss symbols are included in the "Static roots"
 interval, and
 
 b) It doesn't look like there are any obvious unmapped holes in the "Static
 roots" interval.
 
 I would guess that (b) is the problem here.  It may be that the data segment
 in fact starts at a higher address than what the collector is assuming.  The
 collector currently assumes the same spacing between etext and the start of
 the data segment as with the 32 bit ABI.  I think this doesn't work well if
 the page size exceeds 64K, which may have been perceived as a problem by the
 designers of the 64 bit ABI.
 
 If this doesn't lead to a diganosis of the problem, it would also be very
 helpful to extract the fault address somehow.  If you can determine the
 faulting instruction and the corresponding register contents, that should be
 fairly easy.  It wasn't clear to me whather gdb is sufficiently functional
 to do that.
 
 Hans

Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu res with -m64

[Tom Tromey]

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

From: Tom Tromey <tromey@redhat.com>
To: "Boehm, Hans" <hans_boehm@hp.com>
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, gcc-gnats@gcc.gnu.org
Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu 	res with -m64
Date: 15 Apr 2002 15:41:52 -0600

 Hans> That line in GC_stopped_mark calls GC_mark_some.  Thus I would
 Hans> conclude that this version of gdb is only partially functional,
 Hans> and it actually dies somewhere in GC_mark_some().
 
 I agree.
 
 Hans> A possible cause of that is confusion about where the roots are.
 Hans> If you can check GC_stackbottom, check that the collector and
 Hans> libgcj configuration agree on threads, get GC_dump() output, and
 Hans> check the root locations against the nm output that might
 Hans> identify something.  Otherwise we need better debug information.
 
 In order to reduce the number of variables a bit, I tried gctest.  I
 got the same problem.  Here's some info.
 
 (gdb) call GC_dump()
 ***Static roots:
 From 0x100106000 to 0x10012d8b8 
 Total size: 161976
 
 ***Heap sections:
 Total heap size: 131072
 Section 0 from 0x100178000 to 0x100198000 0/16 blacklisted
 
 ***Free blocks:
 Free list 16 (Total size 131072):
 	0x100178000 size 131072 not black listed
 Total of 131072 bytes on free list
 
 ***Blocks in use:
 (kind(0=ptrfree,1=normal,2=unc.,3=stubborn):size_in_bytes, #_marks_set)
 
 blocks = 0, bytes = 0
 
 
 
 (gdb) p GC_stackbottom
 $3 = 0xffffffff80000000 <Address 0xffffffff80000000 out of bounds>
 
 I dug through the source a bit.  I think this machine doesn't define
 USERLIMIT (a simple test program fails), so we must be using HEURISTIC2.
 
 
 When using nm what am I looking for?  I looked at one global,
 GC_gc_no.  Its address falls into the range that GC_dump prints for
 the static roots.  Should I do this comparison for all the globals?
 
 Tom

RE: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failu res with -m64

[Boehm, Hans]

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 ()
 >