RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Boehm, Hans]

I think this part of the patch should be checked into both the branch and
trunk.  If in parallel someone else could try this on other Linux/SPARC
machines, that would help to verify that the main stack base is always
correctly reported in /proc.  But the current code is very hard to defend,
at least given the fact that it isn't always correct.

If you would like me to check it in, please let me know.

I will hold off on the proposed/conjectured Solaris/64 patch since nobody
has been able to test that.

Hans

> -----Original Message-----
> From: Christian Jönsson [mailto:christian@j-son.org]
> Sent: Wednesday, April 17, 2002 12:28 AM
> To: Tom Tromey
> Cc: Boehm, Hans; java@gcc.gnu.org
> Subject: Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
> 
> 
> On Wed, Apr 17, 2002 at 09:22:36AM +0200, chj wrote:
> > On Tue, Apr 16, 2002 at 10:08:45AM -0600, Tom Tromey wrote:
> > > >>>>> "ChJ" == Christian Jönsson 
> <c.christian.joensson@telia.com> writes:
> > > 
> > > ChJ> I applied it to Hans et als. gc6.1alpha4 sources, it seems to
> > > ChJ> work there.
> > > 
> > > Great.
> > > 
> > > ChJ> So Hans, what do we do now? Incorporate your patch 
> into the gcc
> > > ChJ> 3.1 branch and trunk? Test it first in gc6.1alpha5?
> > > 
> > > As I understand it, you couldn't apply this patch to the 
> GC currently
> > > in the gcc tree, right?  Could you modify the patch so it applies
> > > (apply it by hand somehow) and then test that version of the GC?
> > > 
> > > If that works, we will definitely check it in.
> > 
> > I have used the attached patch (based on Hans' first 
> suggested patch).
> 
> ehrm, here it is:
> 
> *** include/private/gcconfig.h.orig	Tue Apr 16 19:08:52 2002
> --- include/private/gcconfig.h	Tue Apr 16 19:14:08 2002
> ***************
> *** 820,830 ****
>         extern int _etext[];
>   #     define DATAEND (_end)
>   #     define SVR4
>   #     ifdef __arch64__
> - #       define STACKBOTTOM ((ptr_t) 0x80000000000ULL)
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, _etext)
>   #     else
> - #       define STACKBOTTOM ((ptr_t) 0xf0000000)
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, _etext)
>   #     endif
>   #   endif
> --- 820,829 ----
>         extern int _etext[];
>   #     define DATAEND (_end)
>   #     define SVR4
> + #     define LINUX_STACKBOTTOM
>   #     ifdef __arch64__
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, _etext)
>   #     else
>   #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, _etext)
>   #     endif
>   #   endif
> 
> 
> > The results are good (however, I happened to throw an an additional
> > --enable-threads that I know cause troubles on sparc32/linux). 
> > 
> > I'd say the proposed patch works for sparc32, and I know Hans has
> > a proposed patch for "all" sparc targets that I hope is in 
> the process
> > of being tested by folks having those arch available.
> 
> <snip>
> 
> Cheers,
> 
> /ChJ
> 

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Wed, Apr 17, 2002 at 09:46:38AM -0700, Boehm, Hans wrote:
> I think this part of the patch should be checked into both the branch and
> trunk.  If in parallel someone else could try this on other Linux/SPARC
> machines, that would help to verify that the main stack base is always
> correctly reported in /proc.  But the current code is very hard to defend,
> at least given the fact that it isn't always correct.
> 
> If you would like me to check it in, please let me know.

pleas go ahead and do so, I'll restart a test build whenever your patch is
in.

> I will hold off on the proposed/conjectured Solaris/64 patch since nobody
> has been able to test that.

That's a good point. I would urge anyone with such an arch to test your
suggested patch. Do you think you could check the sparc32 patch in, branch
and trunk, and then post a suggested patch of the sparc64 remains to
gcc-patches so we will be able to reference it to anyone able to test it?

Cheers,

/ChJ

BTW, thanks for your efforts in sorting this out, easy solved but a long
way :-)

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Wed, Apr 17, 2002 at 09:46:38AM -0700, Boehm, Hans wrote:
> I think this part of the patch should be checked into both the branch and
> trunk.  If in parallel someone else could try this on other Linux/SPARC
> machines, that would help to verify that the main stack base is always
> correctly reported in /proc.  But the current code is very hard to defend,
> at least given the fact that it isn't always correct.

I have now also tested that building and running *gctest* (from gcc-3.1 built
under sparc32/linux-2.2.20 SMP) works under sparc32/linux-2.4.19-pre7 SMP.

Cheers,

/ChJ

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Wed, Apr 17, 2002 at 09:22:36AM +0200, chj wrote:
> On Tue, Apr 16, 2002 at 10:08:45AM -0600, Tom Tromey wrote:
> > >>>>> "ChJ" == Christian Jönsson <c.christian.joensson@telia.com> writes:
> > 
> > ChJ> I applied it to Hans et als. gc6.1alpha4 sources, it seems to
> > ChJ> work there.
> > 
> > Great.
> > 
> > ChJ> So Hans, what do we do now? Incorporate your patch into the gcc
> > ChJ> 3.1 branch and trunk? Test it first in gc6.1alpha5?
> > 
> > As I understand it, you couldn't apply this patch to the GC currently
> > in the gcc tree, right?  Could you modify the patch so it applies
> > (apply it by hand somehow) and then test that version of the GC?
> > 
> > If that works, we will definitely check it in.
> 
> I have used the attached patch (based on Hans' first suggested patch).

ehrm, here it is:

*** include/private/gcconfig.h.orig	Tue Apr 16 19:08:52 2002
--- include/private/gcconfig.h	Tue Apr 16 19:14:08 2002
***************
*** 820,830 ****
        extern int _etext[];
  #     define DATAEND (_end)
  #     define SVR4
  #     ifdef __arch64__
- #       define STACKBOTTOM ((ptr_t) 0x80000000000ULL)
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, _etext)
  #     else
- #       define STACKBOTTOM ((ptr_t) 0xf0000000)
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, _etext)
  #     endif
  #   endif
--- 820,829 ----
        extern int _etext[];
  #     define DATAEND (_end)
  #     define SVR4
+ #     define LINUX_STACKBOTTOM
  #     ifdef __arch64__
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, _etext)
  #     else
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, _etext)
  #     endif
  #   endif


> The results are good (however, I happened to throw an an additional
> --enable-threads that I know cause troubles on sparc32/linux). 
> 
> I'd say the proposed patch works for sparc32, and I know Hans has
> a proposed patch for "all" sparc targets that I hope is in the process
> of being tested by folks having those arch available.

<snip>

Cheers,

/ChJ

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Tue, Apr 16, 2002 at 10:08:45AM -0600, Tom Tromey wrote:
> >>>>> "ChJ" == Christian Jönsson <c.christian.joensson@telia.com> writes:
> 
> ChJ> I applied it to Hans et als. gc6.1alpha4 sources, it seems to
> ChJ> work there.
> 
> Great.
> 
> ChJ> So Hans, what do we do now? Incorporate your patch into the gcc
> ChJ> 3.1 branch and trunk? Test it first in gc6.1alpha5?
> 
> As I understand it, you couldn't apply this patch to the GC currently
> in the gcc tree, right?  Could you modify the patch so it applies
> (apply it by hand somehow) and then test that version of the GC?
> 
> If that works, we will definitely check it in.

I have used the attached patch (based on Hans' first suggested patch).

The results are good (however, I happened to throw an an additional
--enable-threads that I know cause troubles on sparc32/linux). 

I'd say the proposed patch works for sparc32, and I know Hans has
a proposed patch for "all" sparc targets that I hope is in the process
of being tested by folks having those arch available.

Here are the not-yet-quite-ready results:

This was on a Debian Woody (test release) sun4m system with these
packages:

binutils                           2.12.90.0.1-1
dejagnu                            1.4.2-1.1
gcc                                2:2.95.4-14 (Debian prerelease)
gcc-2.95			   1:2.95.4-5 (Debian prerelease)
kernel-image-2.2.20-sun4dm-smp     9
libc6                              2.2.5-4

In-tree joined gcc-3.1 and binutils-2.12 cvs branches.

An unofficial patch to boehm-gc/include/private/gcconfig.h is used.
It makes boehm-gc use LINUX_STACKBOTTOM instead of the "old" method.
I assume this patch is to be incorporated in the branch and trunk
soon.


LAST_UPDATED: Tue Apr 16 18:11:53 UTC 2002

Native configuration is sparc-unknown-linux-gnu

		=== binutils tests ===


Running target unix

		=== binutils Summary ===

# of expected passes		31
# of expected failures		1
		=== gas tests ===


Running target unix

		=== gas Summary ===

# of expected passes		91
		=== g++ tests ===


Running target unix
FAIL: g++.dg/opt/cleanup1.C execution test
		=== gcc tests ===


Running target unix
WARNING: program timed out.
FAIL: gcc.c-torture/compile/20001226-1.c,  -O1  
WARNING: program timed out.
FAIL: gcc.c-torture/compile/20001226-1.c,  -O2  
WARNING: program timed out.
FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer  
WARNING: program timed out.
FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -g  
WARNING: program timed out.
FAIL: gcc.c-torture/compile/20001226-1.c,  -Os  
		=== ld tests ===


Running target unix

		=== ld Summary ===

# of expected passes		129
# of expected failures		13
		=== libjava tests ===


Running target unix
WARNING: program timed out.
FAIL: SyncTest execution from source compiled test
WARNING: program timed out.
FAIL: SyncTest execution from bytecode->native test
WARNING: program timed out.
FAIL: SyncTest -O execution from source compiled test
WARNING: program timed out.
FAIL: SyncTest -O execution from bytecode->native test
FAIL: invokethrow execution from source compiled test
FAIL: invokethrow execution from bytecode->native test
FAIL: invokethrow -O execution from source compiled test
FAIL: invokethrow -O execution from bytecode->native test
FAIL: Throw_2 execution from source compiled test
FAIL: Throw_2 execution from bytecode->native test
FAIL: Throw_2 -O execution from source compiled test
FAIL: Throw_2 -O execution from bytecode->native test

		=== libjava Summary ===

# of expected passes		2037
# of unexpected failures	12
# of expected failures		18
# of untested testcases		26
		=== libstdc++-v3 tests ===


Running target unix
FAIL: 26_numerics/c99_classification_macros_c.cc (test for excess errors)
FAIL: 27_io/filebuf_virtuals.cc execution test
FAIL: 27_io/streambuf.cc execution test
FAIL: 27_io/stringbuf.cc execution test
WARNING: program timed out.
FAIL: thread/pthread1.cc execution test
WARNING: program timed out.
FAIL: thread/pthread5.cc execution test
WARNING: program timed out.
FAIL: thread/pthread6.cc execution test

		=== libstdc++-v3 Summary ===

# of expected passes		366
# of unexpected failures	7
# of expected failures		25

Compiler version: gcc 
Platform: sparc-unknown-linux-gnu
configure flags: --host=sparc-linux --prefix=/usr --enable-shared --enable-threads --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --enable-symvers --without-x --without-included-gettext --disable-checking
Counting all warnings,
there are 225 warnings in stage0 of this bootstrap.

Number of warnings per file:
     96	libiberty/md5.c
     76	libiberty/regex.c
     10	cxa_demangle.c
      8	dyn-string.c
      5	make[3]
      5	libjava/java/lang/natClassLoader.cc
      4	cc1
      3	gcc/unwind-pe.h
      2	make[4]
      2	include/xregex2.h
      2	include/sys/cdefs.h
      2	include/gc.h
      1	make[5]
      1	libsupc++/eh_terminate.cc
      1	libjava/posix-threads.cc
      1	libjava/gnu/gcj/runtime/natSharedLibLoader.cc
      1	libjava/gnu/gcj/io/shs.cc
      1	libjava/boehm.cc
      1	libf2c/libI77/open.c
      1	lex.yy.c
      1	gcc/boehm-gc/mark_rts.c
      1	config.h

Number of warning types:
     64	traditional C rejects string concatenation
     32	function-like macro \`FI' must be used with arguments in traditional C
     32	function-like macro \`FH' must be used with arguments in traditional C
     32	function-like macro \`FG' must be used with arguments in traditional C
     16	implicit declaration of function \`???'
      8	signed and unsigned type in conditional expression
      8	jobserver unavailable: using -j1.  Add \`???' to parent make rule.
      5	unused 
      5	this is the location of the previous definition
      4	unused parameter \`???'
      2	ignoring command line option '-fno-implicit-templates'
      2	control reaches end of 
      2	\`__restrict_arr' redefined
      2	\`GC_LINUX_THREADS' redefined
      2	\`???' defined but not used
      2	(it is valid for C++ but not the selected language)
      1	unused
      1	function returns address of local variable
      1	assignment makes pointer from integer without a cast
      1	\`noreturn'
      1	\`_XOPEN_SOURCE' redefined
      1	\`???' might be 
      1	\`???' 
Counting all warnings,
there are 53 warnings in stage3 of this bootstrap.

Number of warnings per file:
     23	gcc/combine.c
     10	gcc/regclass.c
      4	gcc/optabs.c
      3	gcc/gcc.c
      2	gcc/java/javaop.def
      2	gcc/fold-const.c
      2	gcc/crtstuff.c
      1	gcc/reload.c
      1	gcc/profile.c
      1	gcc/objc/lang-specs.h
      1	gcc/java/jvspec.c
      1	gcc/function.c
      1	gcc/emit-rtl.c
      1	gcc/cp/lang-specs.h

Number of warning types:
     37	comparison between signed and unsigned
      6	string length \`???' is greater than the length \`???' ISO C89 compilers are required to support
      5	signed and unsigned type in conditional expression
      2	operation on \`???' may be undefined
      2	\`???' defined but not used
      1	pointer targets in passing arg ??? of \`???' differ in signedness

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Tom Tromey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

>>>>> "ChJ" == Christian Jönsson <c.christian.joensson@telia.com> writes:

ChJ> I applied it to Hans et als. gc6.1alpha4 sources, it seems to
ChJ> work there.

Great.

ChJ> So Hans, what do we do now? Incorporate your patch into the gcc
ChJ> 3.1 branch and trunk? Test it first in gc6.1alpha5?

As I understand it, you couldn't apply this patch to the GC currently
in the gcc tree, right?  Could you modify the patch so it applies
(apply it by hand somehow) and then test that version of the GC?

If that works, we will definitely check it in.

Thanks,
Tom

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Mon, Apr 15, 2002 at 07:58:54PM -0700, Boehm, Hans wrote:
> That stack pointer value doesn't look a lot like GC_stackbottom.  Just for
> grins, could you try the attached (completely untested) patch?  This makes
> linux/SPARC determine GC_stackbottom in the same way as on other Linux
> platforms, i.e. it first cheats and looks for a private glibc symbol, and
> reads the stack base from /proc if that fails.

I applied it to Hans et als. gc6.1alpha4 sources, it seems to work there.

Here's the output of make test (which used to yield a seg. viol.)

./setjmp_test
This appears to be a SPARC running LINUX
Stack appears to grow down, which is the default.
A good guess for STACKBOTTOM on this machine is 0xe8fff000.
Note that this may vary between machines of ostensibly
the same architecture (e.g. Sun 3/50s and 3/80s).
On many machines the value is not fixed.
A good guess for ALIGNMENT on this machine is 4.
Generic mark_regs code probably wont work
Assembly code supplied
./gctest
Completed 1 tests
Allocated 648421 collectable objects
Allocated 101 uncollectable objects
Allocated 1250000 atomic objects
Allocated 10880 stubborn objects
Finalized 2204/2206 objects - finalization is probably ok
Total number of bytes allocated is 60648304
Final heap size is 4157440 bytes
Collector appears to work
gcc  -g -I./include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS -c -I. ./cord/cordbscs.c
mv cordbscs.o cord/cordbscs.o
gcc  -g -I./include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS -c -I. ./cord/cordxtra.c
mv cordxtra.o cord/cordxtra.o
gcc  -g -I./include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS -c -I. ./cord/cordprnt.c
mv cordprnt.o cord/cordprnt.o
rm -f cord/cordtest
./if_mach SPARC DRSNX gcc  -g -I./include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS -o cord/cordtest ./cord/cordtest.c cord/cordbscs.o cord/cordxtra.o cord/cordprnt.o gc.a -lucb
./if_mach HP_PA HPUX gcc  -g -I./include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS -o cord/cordtest ./cord/cordtest.c cord/cordbscs.o cord/cordxtra.o cord/cordprnt.o gc.a -ldld `./threadlibs`
./if_mach M68K AMIGA gcc  -g -I./include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS -UGC_AMIGA_MAKINGLIB -o cord/cordtest ./cord/cordtest.c cord/cordbscs.o cord/cordxtra.o cord/cordprnt.o gc.a `./threadlibs`
./if_not_there cord/cordtest gcc  -g -I./include -DATOMIC_UNCOLLECTABLE -DNO_SIGNALS -DNO_EXECUTE_PERMISSION -DSILENT -DALL_INTERIOR_POINTERS -o cord/cordtest ./cord/cordtest.c cord/cordbscs.o cord/cordxtra.o cord/cordprnt.o gc.a `./threadlibs`
^^^^Starting command^^^^
cord/cordtest
SUCCEEDED


So Hans, what do we do now? Incorporate your patch into the gcc 3.1 branch
and trunk? Test it first in gc6.1alpha5?

Cheers,

/ChJ

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Mon, Apr 15, 2002 at 07:58:54PM -0700, Boehm, Hans wrote:
> That stack pointer value doesn't look a lot like GC_stackbottom.  Just for
> grins, could you try the attached (completely untested) patch?  This makes
> linux/SPARC determine GC_stackbottom in the same way as on other Linux
> platforms, i.e. it first cheats and looks for a private glibc symbol, and
> reads the stack base from /proc if that fails.

This is a good idea to test I guess. But, the patch didn't apply
cleanly to my gcc-3.1 (Mon Apr 15 06:18:21 UTC 2002) sources.

***************
*** 815,825 ****
        extern int _etext;
  #     define DATAEND (&_end)
  #     define SVR4
  #     ifdef __arch64__
- #       define STACKBOTTOM ((ptr_t) 0x80000000000ULL)
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, &_etext)
  #     else
- #       define STACKBOTTOM ((ptr_t) 0xf0000000)
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, &_etext)
  #     endif
  #   endif
--- 815,824 ----
        extern int _etext;
  #     define DATAEND (&_end)
  #     define SVR4
+ #     define LINUX_STACKBOTTOM
  #     ifdef __arch64__
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, &_etext)
  #     else
  #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, &_etext)
  #     endif
  #   endif


Hans, would you like me to update my gcc-3.1 source tree and patch
that and issue a rebuild or could you perhaps tell me what to do with
this particular case?

Cheers,

/ChJ

RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Boehm, Hans]

[-- Attachment #1: Type: text/plain, Size: 5067 bytes --]

That stack pointer value doesn't look a lot like GC_stackbottom.  Just for
grins, could you try the attached (completely untested) patch?  This makes
linux/SPARC determine GC_stackbottom in the same way as on other Linux
platforms, i.e. it first cheats and looks for a private glibc symbol, and
reads the stack base from /proc if that fails.

Hans

> -----Original Message-----
> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> Sent: Sunday, April 14, 2002 1:16 PM
> To: Boehm, Hans
> Cc: Tom Tromey; java@gcc.gnu.org
> Subject: Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
> 
> 
> On Wed, Apr 10, 2002 at 11:11:19AM -0700, Boehm, Hans wrote:
> > The new trace looks very similar to the old one to me.  
> There's still a lot
> > of space between "bottom" and "top" in GC_push_all_eager.  
> Does the stack
> > base look plausible?  If you stop the program in main(), what's $sp?
> > 
> > Hans
> 
> Well, here's what's in there for today's (Sun Apr 14 07:33:16 
> UTC 2002):
> 
> Current directory is 
> /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/
> GNU gdb 5.1.90_20020403
> Copyright 2002 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 "sparc-linux"...
> (gdb) break main
> Breakpoint 1 at 0x10ac0: file /tmp/cctyn6m2.i, line 10.
> (gdb) r
> Starting program: 
> /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/cxxtest 
> 
> Breakpoint 1, main (argc=1, argv=0xe8ffec74) at /tmp/cctyn6m2.i:10
> 10	/tmp/cctyn6m2.i: No such file or directory.
> 	in /tmp/cctyn6m2.i
> (gdb) print $sp
> $1 = -385881272
> (gdb) c
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x507005f0 in GC_push_all_eager (bottom=0xe8ffe634 "ð\031@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> (gdb) bt
> #0  0x507005f0 in GC_push_all_eager (bottom=0xe8ffe634 "ð\031@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> #1  0x507006e8 in GC_push_all_stack_partially_eager (
>     bottom=0xe8ffe634 "ð\031@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
>     cold_gc_frame=0xe8ffe81c "") at 
> /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
> #2  0x5070251c in GC_push_current_stack (cold_gc_frame=0xe8ffe81c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:457
> #3  0x50702684 in GC_push_roots (all=1, cold_gc_frame=0xe8ffe81c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:571
> #4  0x506fe380 in GC_mark_some (cold_gc_frame=0xe8ffe81c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:322
> #5  0x506f4548 in GC_stopped_mark (stop_func=0x506f36c8 
> <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:489
> #6  0x506f40d0 in GC_try_to_collect_inner (
>     stop_func=0x506f36c8 <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:350
> #7  0x50703840 in GC_init_inner () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:673
> #8  0x507032ac in GC_init () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:455
> #9  0x506fa4f0 in GC_init_gcj_malloc (mp_index=0, mp=0x506f063c)
>     at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
> #10 0x506f1298 in _Jv_InitGC() () at 
> /share2/gcc-rel/gcc/libjava/boehm.cc:465
> #11 0x5053e914 in _Jv_CreateJavaVM(void*) ()
>     at /share2/gcc-rel/gcc/libjava/prims.cc:892
> #12 0x5053ed38 in _Jv_RunMain(java::lang::Class*, char 
> const*, int, char const**, bool) (klass=0x2101c, name=0x0, 
> argc=1, argv=0xe8ffec74, is_jar=false)
>     at /share2/gcc-rel/gcc/libjava/prims.cc:982
> #13 0x00010aec in main (argc=1, argv=0xe8ffec74) at /tmp/cctyn6m2.i:11
> (gdb) print $sp
> $2 = -385882800
> (gdb) call GC_dump()
> ***Static roots:
> From 0x20e58 to 0x21498 
> From 0x50039b38 to 0x50039d58  (temporary)
> From 0x500df7c8 to 0x500f3ff8  (temporary)
> From 0x50186118 to 0x50188470  (temporary)
> From 0x5019fed0 to 0x501a07b8  (temporary)
> From 0x502d7000 to 0x502e21a8  (temporary)
> From 0x50796970 to 0x508ae1b0  (temporary)
> From 0x508cbc68 to 0x508cd3e8  (temporary)
> From 0x508de000 to 0x508de370  (temporary)
> Total size: 1294760
> 
> ***Heap sections:
> Total heap size: 65536
> Section 0 from 0x44000 to 0x54000 0/16 blacklisted
> 
> ***Free blocks:
> Free list 16 (Total size 65536):
> 	0x44000 size 65536 not black listed
> Total of 65536 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) c
> Continuing.
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> (gdb) quit
> 
> Debugger finished
> 
> Cheers,
> 
> /ChJ
> 


[-- Attachment #2: sparc.diff --]
[-- Type: application/octet-stream, Size: 525 bytes --]

--- gcconfig.h	Mon Apr  8 16:37:20 2002
+++ gcconfig.h.sparc	Mon Apr 15 19:53:46 2002
@@ -815,11 +815,10 @@
       extern int _etext;
 #     define DATAEND (&_end)
 #     define SVR4
+#     define LINUX_STACKBOTTOM
 #     ifdef __arch64__
-#       define STACKBOTTOM ((ptr_t) 0x80000000000ULL)
 #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x100000, &_etext)
 #     else
-#       define STACKBOTTOM ((ptr_t) 0xf0000000)
 #	define DATASTART (ptr_t)GC_SysVGetDataStart(0x10000, &_etext)
 #     endif
 #   endif

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Wed, Apr 10, 2002 at 11:11:19AM -0700, Boehm, Hans wrote:
> The new trace looks very similar to the old one to me.  There's still a lot
> of space between "bottom" and "top" in GC_push_all_eager.  Does the stack
> base look plausible?  If you stop the program in main(), what's $sp?
> 
> Hans

Well, here's what's in there for today's (Sun Apr 14 07:33:16 UTC 2002):

Current directory is /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/
GNU gdb 5.1.90_20020403
Copyright 2002 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 "sparc-linux"...
(gdb) break main
Breakpoint 1 at 0x10ac0: file /tmp/cctyn6m2.i, line 10.
(gdb) r
Starting program: /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/cxxtest 

Breakpoint 1, main (argc=1, argv=0xe8ffec74) at /tmp/cctyn6m2.i:10
10	/tmp/cctyn6m2.i: No such file or directory.
	in /tmp/cctyn6m2.i
(gdb) print $sp
$1 = -385881272
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x507005f0 in GC_push_all_eager (bottom=0xe8ffe634 "ð\031@", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>)
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
(gdb) bt
#0  0x507005f0 in GC_push_all_eager (bottom=0xe8ffe634 "ð\031@", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>)
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
#1  0x507006e8 in GC_push_all_stack_partially_eager (
    bottom=0xe8ffe634 "ð\031@", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>, 
    cold_gc_frame=0xe8ffe81c "") at /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
#2  0x5070251c in GC_push_current_stack (cold_gc_frame=0xe8ffe81c "")
    at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:457
#3  0x50702684 in GC_push_roots (all=1, cold_gc_frame=0xe8ffe81c "")
    at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:571
#4  0x506fe380 in GC_mark_some (cold_gc_frame=0xe8ffe81c "")
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:322
#5  0x506f4548 in GC_stopped_mark (stop_func=0x506f36c8 <GC_never_stop_func>)
    at /share2/gcc-rel/gcc/boehm-gc/alloc.c:489
#6  0x506f40d0 in GC_try_to_collect_inner (
    stop_func=0x506f36c8 <GC_never_stop_func>)
    at /share2/gcc-rel/gcc/boehm-gc/alloc.c:350
#7  0x50703840 in GC_init_inner () at /share2/gcc-rel/gcc/boehm-gc/misc.c:673
#8  0x507032ac in GC_init () at /share2/gcc-rel/gcc/boehm-gc/misc.c:455
#9  0x506fa4f0 in GC_init_gcj_malloc (mp_index=0, mp=0x506f063c)
    at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
#10 0x506f1298 in _Jv_InitGC() () at /share2/gcc-rel/gcc/libjava/boehm.cc:465
#11 0x5053e914 in _Jv_CreateJavaVM(void*) ()
    at /share2/gcc-rel/gcc/libjava/prims.cc:892
#12 0x5053ed38 in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) (klass=0x2101c, name=0x0, argc=1, argv=0xe8ffec74, is_jar=false)
    at /share2/gcc-rel/gcc/libjava/prims.cc:982
#13 0x00010aec in main (argc=1, argv=0xe8ffec74) at /tmp/cctyn6m2.i:11
(gdb) print $sp
$2 = -385882800
(gdb) call GC_dump()
***Static roots:
From 0x20e58 to 0x21498 
From 0x50039b38 to 0x50039d58  (temporary)
From 0x500df7c8 to 0x500f3ff8  (temporary)
From 0x50186118 to 0x50188470  (temporary)
From 0x5019fed0 to 0x501a07b8  (temporary)
From 0x502d7000 to 0x502e21a8  (temporary)
From 0x50796970 to 0x508ae1b0  (temporary)
From 0x508cbc68 to 0x508cd3e8  (temporary)
From 0x508de000 to 0x508de370  (temporary)
Total size: 1294760

***Heap sections:
Total heap size: 65536
Section 0 from 0x44000 to 0x54000 0/16 blacklisted

***Free blocks:
Free list 16 (Total size 65536):
	0x44000 size 65536 not black listed
Total of 65536 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) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) quit

Debugger finished

Cheers,

/ChJ

RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Boehm, Hans]

The new trace looks very similar to the old one to me.  There's still a lot
of space between "bottom" and "top" in GC_push_all_eager.  Does the stack
base look plausible?  If you stop the program in main(), what's $sp?

Hans

> -----Original Message-----
> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> Sent: Wednesday, April 10, 2002 1:20 AM
> To: Boehm, Hans
> Cc: Tom Tromey; java@gcc.gnu.org
> Subject: Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?
> 
> 
> On Tue, Apr 09, 2002 at 06:19:01PM -0700, Boehm, Hans wrote:
> > > -----Original Message-----
> > > From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> > > (gdb) r
> > > Starting program: 
> > > /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/l
> > > ibjava/testsuite/cxxtest 
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
> > >     top=0xf0000000 <Address 0xf0000000 out of bounds>)
> > >     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> > > 1349		q = *p;
> > > (gdb) bt
> > > #0  0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 
> "P\0022H@", 
> > >     top=0xf0000000 <Address 0xf0000000 out of bounds>)
> > >     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> > > #1  0x506d7058 in GC_push_all_stack_partially_eager (
> > >     bottom=0xeaffe3d4 "P\0022H@", 
> > >     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
> > >     cold_gc_frame=0xeaffe5bc "") at 
> > > /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
> > 
> > This is actually rather suggestive.  It was trying to mark 
> a stack between
> > 0xeaffe3d4 and 0xf0000000.  That's a big stack.  I suspect 
> one of the
> > following:
> > 
> > 1) Java is compiled with thread support, but the collector 
> gets configures
> > without GC_LINUX_THREADS defined.  Thus it's trying to mark 
> between a thread
> > stack pointer and the base of the main stack.
> > 
> > 2) The default stack base of (specified in gcconfig.h) of 
> 0xf0000000 is
> > wrong on your machine.  Try stopping a toy program in main 
> and print $sp
> > from gdb to see whether the stack base looks plausible.
> 
> I'm afraid I ran this test on a ss20 UP machine, and not the ss20 SMP
> machine I built on... Here's a new run for gcc-3.1 2002-04-08.
> 
> This was on a Debian Woody (test release) sun4m system with these
> packages:
> 
> binutils                           2.12.90.0.1-1
> dejagnu                            1.4.2-1.1
> gcc                                2:2.95.4-14 (Debian prerelease)
> gcc-2.95			   1:2.95.4-5 (Debian prerelease)
> kernel-image-2.2.20-sun4dm-smp     9
> libc6                              2.2.5-4
> 
> LAST_UPDATED: Tue Apr  9 06:34:44 UTC 2002
> 
> 
> # This directory was configured as follows:
> /share2/gcc-rel/gcc/configure --host=sparc-linux 
> --prefix=/usr --enable-shared --with-gnu-as --with-gnu-ld 
> --with-system-zlib --enable-long-long --enable-nlls 
> --enable-symvers --without-x --without-included-gettext 
> --disable-checking
> 
> 
> i.e., no threads as some suspect threads problems.
> 
> 
> chj@fw:/share2/gcc-rel/objdir/sparc-linux/libjava/testsuite$ 
> env 
> LD_LIBRARY_PATH=`pwd`/../.libs:`pwd`/../../../gcc:.:/usr/lib/d
> ebug ~/gdb cxxtest
> GNU gdb 5.1.90_20020403
> Copyright 2002 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 "sparc-linux"...
> (gdb) r
> Starting program: 
> /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/cxxtest 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x506d9bc8 in GC_push_all_eager (bottom=0xeaffe444 "P\0020", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> 1349		q = *p;
> (gdb) bt
> #0  0x506d9bc8 in GC_push_all_eager (bottom=0xeaffe444 "P\0020", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> #1  0x506d9cc0 in GC_push_all_stack_partially_eager (
>     bottom=0xeaffe444 "P\0020", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
>     cold_gc_frame=0xeaffe62c "") at 
> /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
> #2  0x506dbaf0 in GC_push_current_stack (cold_gc_frame=0xeaffe62c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:457
> #3  0x506dbc58 in GC_push_roots (all=1, cold_gc_frame=0xeaffe62c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:571
> #4  0x506d7958 in GC_mark_some (cold_gc_frame=0xeaffe62c "")
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:322
> #5  0x506cdb20 in GC_stopped_mark (stop_func=0x506ccca0 
> <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:489
> #6  0x506cd6a8 in GC_try_to_collect_inner (
>     stop_func=0x506ccca0 <GC_never_stop_func>)
>     at /share2/gcc-rel/gcc/boehm-gc/alloc.c:350
> #7  0x506dce14 in GC_init_inner () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:673
> #8  0x506dc880 in GC_init () at 
> /share2/gcc-rel/gcc/boehm-gc/misc.c:455
> #9  0x506d3ac8 in GC_init_gcj_malloc (mp_index=0, mp=0x506c9c14)
>     at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
> #10 0x506ca870 in _Jv_InitGC() () at 
> /share2/gcc-rel/gcc/libjava/boehm.cc:465
> #11 0x5053f8fc in _Jv_CreateJavaVM(void*) ()
>     at /share2/gcc-rel/gcc/libjava/prims.cc:892
> #12 0x5053fd20 in _Jv_RunMain(java::lang::Class*, char 
> const*, int, char const**, bool) (klass=0x20f74, name=0x0, 
> argc=1, argv=0xeaffea84, is_jar=false)
>     at /share2/gcc-rel/gcc/libjava/prims.cc:982
> #13 0x00010aac in main (argc=1, argv=0xeaffea84) at /tmp/cclCWPMk.i:11
> (gdb) c
> Continuing.
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> (gdb) 
> 

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Tue, Apr 09, 2002 at 06:19:01PM -0700, Boehm, Hans wrote:
> > -----Original Message-----
> > From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> > (gdb) r
> > Starting program: 
> > /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/l
> > ibjava/testsuite/cxxtest 
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
> >     top=0xf0000000 <Address 0xf0000000 out of bounds>)
> >     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> > 1349		q = *p;
> > (gdb) bt
> > #0  0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
> >     top=0xf0000000 <Address 0xf0000000 out of bounds>)
> >     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> > #1  0x506d7058 in GC_push_all_stack_partially_eager (
> >     bottom=0xeaffe3d4 "P\0022H@", 
> >     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
> >     cold_gc_frame=0xeaffe5bc "") at 
> > /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
> 
> This is actually rather suggestive.  It was trying to mark a stack between
> 0xeaffe3d4 and 0xf0000000.  That's a big stack.  I suspect one of the
> following:
> 
> 1) Java is compiled with thread support, but the collector gets configures
> without GC_LINUX_THREADS defined.  Thus it's trying to mark between a thread
> stack pointer and the base of the main stack.
> 
> 2) The default stack base of (specified in gcconfig.h) of 0xf0000000 is
> wrong on your machine.  Try stopping a toy program in main and print $sp
> from gdb to see whether the stack base looks plausible.

I'm afraid I ran this test on a ss20 UP machine, and not the ss20 SMP
machine I built on... Here's a new run for gcc-3.1 2002-04-08.

This was on a Debian Woody (test release) sun4m system with these
packages:

binutils                           2.12.90.0.1-1
dejagnu                            1.4.2-1.1
gcc                                2:2.95.4-14 (Debian prerelease)
gcc-2.95			   1:2.95.4-5 (Debian prerelease)
kernel-image-2.2.20-sun4dm-smp     9
libc6                              2.2.5-4

LAST_UPDATED: Tue Apr  9 06:34:44 UTC 2002


# This directory was configured as follows:
/share2/gcc-rel/gcc/configure --host=sparc-linux --prefix=/usr --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --enable-symvers --without-x --without-included-gettext --disable-checking


i.e., no threads as some suspect threads problems.


chj@fw:/share2/gcc-rel/objdir/sparc-linux/libjava/testsuite$ env LD_LIBRARY_PATH=`pwd`/../.libs:`pwd`/../../../gcc:.:/usr/lib/debug ~/gdb cxxtest
GNU gdb 5.1.90_20020403
Copyright 2002 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 "sparc-linux"...
(gdb) r
Starting program: /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/cxxtest 

Program received signal SIGSEGV, Segmentation fault.
0x506d9bc8 in GC_push_all_eager (bottom=0xeaffe444 "P\0020", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>)
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
1349		q = *p;
(gdb) bt
#0  0x506d9bc8 in GC_push_all_eager (bottom=0xeaffe444 "P\0020", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>)
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
#1  0x506d9cc0 in GC_push_all_stack_partially_eager (
    bottom=0xeaffe444 "P\0020", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>, 
    cold_gc_frame=0xeaffe62c "") at /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
#2  0x506dbaf0 in GC_push_current_stack (cold_gc_frame=0xeaffe62c "")
    at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:457
#3  0x506dbc58 in GC_push_roots (all=1, cold_gc_frame=0xeaffe62c "")
    at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:571
#4  0x506d7958 in GC_mark_some (cold_gc_frame=0xeaffe62c "")
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:322
#5  0x506cdb20 in GC_stopped_mark (stop_func=0x506ccca0 <GC_never_stop_func>)
    at /share2/gcc-rel/gcc/boehm-gc/alloc.c:489
#6  0x506cd6a8 in GC_try_to_collect_inner (
    stop_func=0x506ccca0 <GC_never_stop_func>)
    at /share2/gcc-rel/gcc/boehm-gc/alloc.c:350
#7  0x506dce14 in GC_init_inner () at /share2/gcc-rel/gcc/boehm-gc/misc.c:673
#8  0x506dc880 in GC_init () at /share2/gcc-rel/gcc/boehm-gc/misc.c:455
#9  0x506d3ac8 in GC_init_gcj_malloc (mp_index=0, mp=0x506c9c14)
    at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
#10 0x506ca870 in _Jv_InitGC() () at /share2/gcc-rel/gcc/libjava/boehm.cc:465
#11 0x5053f8fc in _Jv_CreateJavaVM(void*) ()
    at /share2/gcc-rel/gcc/libjava/prims.cc:892
#12 0x5053fd20 in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) (klass=0x20f74, name=0x0, argc=1, argv=0xeaffea84, is_jar=false)
    at /share2/gcc-rel/gcc/libjava/prims.cc:982
#13 0x00010aac in main (argc=1, argv=0xeaffea84) at /tmp/cclCWPMk.i:11
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) 

RE: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Boehm, Hans]

> -----Original Message-----
> From: Christian Jönsson [mailto:c.christian.joensson@telia.com]
> (gdb) r
> Starting program: 
> /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/l
> ibjava/testsuite/cxxtest 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> 1349		q = *p;
> (gdb) bt
> #0  0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>)
>     at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
> #1  0x506d7058 in GC_push_all_stack_partially_eager (
>     bottom=0xeaffe3d4 "P\0022H@", 
>     top=0xf0000000 <Address 0xf0000000 out of bounds>, 
>     cold_gc_frame=0xeaffe5bc "") at 
> /share2/gcc-rel/gcc/boehm-gc/mark.c:1386

This is actually rather suggestive.  It was trying to mark a stack between
0xeaffe3d4 and 0xf0000000.  That's a big stack.  I suspect one of the
following:

1) Java is compiled with thread support, but the collector gets configures
without GC_LINUX_THREADS defined.  Thus it's trying to mark between a thread
stack pointer and the base of the main stack.

2) The default stack base of (specified in gcconfig.h) of 0xf0000000 is
wrong on your machine.  Try stopping a toy program in main and print $sp
from gdb to see whether the stack base looks plausible.

Hans

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Tom Tromey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

>>>>> "ChJ" == Christian Jönsson <c.christian.joensson@telia.com> writes:

ChJ> This GDB was configured as "sparc-linux"...

ChJ> Program received signal SIGSEGV, Segmentation fault.
ChJ> 0x506de908 in GC_SysVGetDataStart (max_page_size=65536, etext_addr=0x10f24)
ChJ>     at /share2/gcc-rel/gcc/boehm-gc/os_dep.c:1063
ChJ> 1063	    	*result = *result;

This isn't the actual problem.  This line deliberately provokes a segv
which is caught.  Try running the debugger again but `cont' after this
to the real failure.

Tom

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Mon, Apr 08, 2002 at 11:07:48PM +0200, chj wrote:
> On Mon, Apr 08, 2002 at 02:16:31PM -0600, Tom Tromey wrote:
> > >>>>> "ChJ" == Christian Jönsson <c.christian.joensson@telia.com> writes:
> > 
> > ChJ> Sorry, I should have inserted a pointer to my latest
> > ChJ> testresults... Here it is:
> > ChJ> http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00182.html
> > 
> > Hi.  I'm finally back, and I looked at this today.
> > It looks to me like all the execute tests are failing.  Usually this
> > indicates some systematic low-level failure.
> 
> I would think so, yes. I also suspect, as have been suggested to me by
> others, that there might be a sun4m, i.e., sparc32, kernel problem
> relevant also for this.
> 
> > 
> > It would help if you could send a piece of the libjava.log file that
> > shows a single such failure.


This is from gcc-3.1 (Tue Apr  9 06:34:44 UTC 2002):


chj@fw:/share2/gcc-rel/objdir/sparc-linux/libjava/testsuite$ env LD_LIBRARY_PATH=`pwd`/../.libs:`pwd`/../../../gcc:. ~/gdb cxxtest
GNU gdb 5.1.90_20020403
Copyright 2002 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 "sparc-linux"...
(gdb) r
Starting program: /share2/gcc-rel/objdir/sparc-linux/libjava/testsuite/cxxtest 

Program received signal SIGSEGV, Segmentation fault.
0x506de908 in GC_SysVGetDataStart (max_page_size=65536, etext_addr=0x10f24)
    at /share2/gcc-rel/gcc/boehm-gc/os_dep.c:1063
1063	    	*result = *result;
(gdb) bt
#0  0x506de908 in GC_SysVGetDataStart (max_page_size=65536, etext_addr=0x10f24)
    at /share2/gcc-rel/gcc/boehm-gc/os_dep.c:1063
#1  0x506de984 in GC_register_data_segments ()
    at /share2/gcc-rel/gcc/boehm-gc/os_dep.c:1101
#2  0x506dcc60 in GC_init_inner () at /share2/gcc-rel/gcc/boehm-gc/misc.c:622
#3  0x506dc880 in GC_init () at /share2/gcc-rel/gcc/boehm-gc/misc.c:455
#4  0x506d3ac8 in GC_init_gcj_malloc (mp_index=0, mp=0x506c9c14)
    at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
#5  0x506ca870 in _Jv_InitGC() () at /share2/gcc-rel/gcc/libjava/boehm.cc:465
#6  0x5053f8fc in _Jv_CreateJavaVM(void*) ()
    at /share2/gcc-rel/gcc/libjava/prims.cc:892
#7  0x5053fd20 in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) (klass=0x210ec, name=0x0, argc=1, argv=0xeaffea84, is_jar=false)
    at /share2/gcc-rel/gcc/libjava/prims.cc:982
#8  0x00010bb0 in main (argc=1, argv=0xeaffea84) at /tmp/ccuN8h6S.i:11
(gdb) q
The program is running.  Exit anyway? (y or n) y
chj@fw:/share2/gcc-rel/objdir/sparc-linux/libjava/testsuite$ 



/ChJ

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Mon, Apr 08, 2002 at 02:16:31PM -0600, Tom Tromey wrote:
> >>>>> "ChJ" == Christian Jönsson <c.christian.joensson@telia.com> writes:
> 
> ChJ> Sorry, I should have inserted a pointer to my latest
> ChJ> testresults... Here it is:
> ChJ> http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00182.html
> 
> Hi.  I'm finally back, and I looked at this today.
> It looks to me like all the execute tests are failing.  Usually this
> indicates some systematic low-level failure.

I would think so, yes. I also suspect, as have been suggested to me by
others, that there might be a sun4m, i.e., sparc32, kernel problem
relevant also for this.

> 
> It would help if you could send a piece of the libjava.log file that
> shows a single such failure.

Sure, this is from my current ongoing test of gcc-3.1 (Sun Apr 7
12:38:08 UTC 2002):

Running /share2/gcc-rel/gcc/libjava/testsuite/libjava.jni/jni.exp ...
PASS: bytecompile /share2/gcc-rel/gcc/libjava/testsuite/libjava.jni/calls.java
PASS: calls header generation
Executing on host: /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/xgcc -B/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/ /share2/gcc-rel/gcc/libjava/testsuite/libjava.jni/calls.c  -shared -fPIC -I. -I.. -I/share2/gcc-rel/gcc/libjava/testsuite/../include  -lm   -fPIC -o libcalls.so    (timeout = 300)
PASS: calls.c compilation
Executing on host: /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/gcj -B/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/ --encoding=UTF-8 -B/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite/../ /share2/gcc-rel/gcc/libjava/testsuite/libjava.jni/calls.java   -no-install -fjni -L. -lcalls  --main=calls -g  -L/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux//libjava/.libs -L/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux//boehm-gc/.libs -lm   -fPIC -o calls    (timeout = 300)
PASS: linking calls
FAIL: calls run
UNTESTED: calls output

PASS: cxxtest header generation
Executing on host: /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/xgcc -B/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/ /share2/gcc-rel/gcc/libjava/testsuite/libjava.jni/cxxtest.cc  -shared -fPIC -I. -I.. -I/share2/gcc-rel/gcc/libjava/testsuite/../include  -lm   -fPIC -o libcxxtest.so    (timeout = 300)
PASS: cxxtest.c compilation
Executing on host: /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/gcj -B/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/gcc/ --encoding=UTF-8 -B/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite/../ /share2/gcc-rel/gcc/libjava/testsuite/libjava.jni/cxxtest.java   -no-install -fjni -L. -lcxxtest -L/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libstdc++-v3/src -lstdc++ --main=cxxtest -g  -L/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux//libjava/.libs -L/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux//boehm-gc/.libs -lm   -fPIC -o cxxtest    (timeout = 300)
PASS: linking cxxtest
FAIL: cxxtest run
UNTESTED: cxxtest output

Not much I get out of that...
 
> Also, you could try running one of the programs by hand from the
> command line.  Even running a simple "hello world" program should show
> the problem.

Sorry, you'll perhaps have to help me a bit more here.

Here's what I do (the unix run, not -fPIC or -fpic):

chj@fw:/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite$ env LD_LIBRARY_PATH=`pwd`/../.libs:`pwd`/../../../gcc:. ldd cxxtest
	libcxxtest.so => ./libcxxtest.so (0x50029000)
	libstdc++.so.4 => /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libstdc++-v3/src/.libs/libstdc++.so.4 (0x5003a000)
	libm.so.6 => /lib/libm.so.6 (0x500f5000)
	libgcc_s.so.1 => /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite/../../../gcc/libgcc_s.so.1 (0x5018a000)
	libc.so.6 => /lib/libc.so.6 (0x501a2000)
	libgcj.so.3 => /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite/../.libs/libgcj.so.3 (0x502e4000)
	libz.so.1 => /usr/lib/libz.so.1 (0x50884000)
	libdl.so.2 => /lib/libdl.so.2 (0x508a3000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x50000000)
chj@fw:/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite$ env LD_LIBRARY_PATH=`pwd`/../.libs:`pwd`/../../../gcc:. ~/gdb cxxtest
GNU gdb 5.1.90_20020403
Copyright 2002 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 "sparc-linux"...
(gdb) r
Starting program: /share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite/cxxtest 

Program received signal SIGSEGV, Segmentation fault.
0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>)
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
1349		q = *p;
(gdb) bt
#0  0x506d6f60 in GC_push_all_eager (bottom=0xeaffe3d4 "P\0022H@", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>)
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:1349
#1  0x506d7058 in GC_push_all_stack_partially_eager (
    bottom=0xeaffe3d4 "P\0022H@", 
    top=0xf0000000 <Address 0xf0000000 out of bounds>, 
    cold_gc_frame=0xeaffe5bc "") at /share2/gcc-rel/gcc/boehm-gc/mark.c:1386
#2  0x506d8e88 in GC_push_current_stack (cold_gc_frame=0xeaffe5bc "")
    at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:457
#3  0x506d8ff0 in GC_push_roots (all=1, cold_gc_frame=0xeaffe5bc "")
    at /share2/gcc-rel/gcc/boehm-gc/mark_rts.c:571
#4  0x506d4ca0 in GC_mark_some (cold_gc_frame=0xeaffe5bc "")
    at /share2/gcc-rel/gcc/boehm-gc/mark.c:322
#5  0x506cae54 in GC_stopped_mark (stop_func=0x506c9fbc <GC_never_stop_func>)
    at /share2/gcc-rel/gcc/boehm-gc/alloc.c:489
#6  0x506ca9dc in GC_try_to_collect_inner (
    stop_func=0x506c9fbc <GC_never_stop_func>)
    at /share2/gcc-rel/gcc/boehm-gc/alloc.c:350
#7  0x506da12c in GC_init_inner () at /share2/gcc-rel/gcc/boehm-gc/misc.c:652
#8  0x506d9c4c in GC_init () at /share2/gcc-rel/gcc/boehm-gc/misc.c:448
#9  0x506d0e10 in GC_init_gcj_malloc (mp_index=0, mp=0x506c6f98)
    at /share2/gcc-rel/gcc/boehm-gc/gcj_mlc.c:60
#10 0x506c7bf0 in _Jv_InitGC() () at /share2/gcc-rel/gcc/libjava/boehm.cc:465
#11 0x5053f798 in _Jv_CreateJavaVM(void*) ()
    at /share2/gcc-rel/gcc/libjava/prims.cc:892
#12 0x5053fbbc in _Jv_RunMain(java::lang::Class*, char const*, int, char const**, bool) (klass=0x20f9c, name=0x0, argc=1, argv=0xeaffea14, is_jar=false)
    at /share2/gcc-rel/gcc/libjava/prims.cc:982
#13 0x00010ad4 in main (argc=1, argv=0xeaffea14) at /tmp/cc0Rw3pF.i:11
(gdb) quit
The program is running.  Exit anyway? (y or n) y
chj@fw:/share2/gcc-rel/objdir-gcc-3.1+binutils-2.12-cvs/sparc-linux/libjava/testsuite$

 
> We can start debugging from there...

Sure, this is what I got. See also 

http://gcc.gnu.org/ml/gcc-bugs/2002-04/msg00401.html

or around that thread as I suspect they might be related :-)
 
> Thanks for looking at this platform!

No problem, my fun.

Cheers,

/ChJ

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Tom Tromey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

>>>>> "ChJ" == Christian Jönsson <c.christian.joensson@telia.com> writes:

ChJ> Sorry, I should have inserted a pointer to my latest
ChJ> testresults... Here it is:
ChJ> http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00182.html

Hi.  I'm finally back, and I looked at this today.
It looks to me like all the execute tests are failing.  Usually this
indicates some systematic low-level failure.

It would help if you could send a piece of the libjava.log file that
shows a single such failure.

Also, you could try running one of the programs by hand from the
command line.  Even running a simple "hello world" program should show
the problem.

We can start debugging from there...

Thanks for looking at this platform!

Tom

Re: gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

On Fri, Apr 05, 2002 at 07:26:54PM +0200, chj wrote:
> Hej Tom.
> 
> I am test building the gcc-3.1 prereleases on sparc-linux, n.b.,
> debian, no more sparc support from redhat...
> 
> The results of the testsuite is getting better and better, but libjava
> still has a lot of failures.


Sorry, I should have inserted a pointer to my latest
testresults... Here it is:

http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00182.html

Cheers,

/ChJ

> 
> Could you perhaps elaborate a little on what you think might be the
> causes behind these failures?
> 
> I know that the support for sparc32 in the linux kernel is lagging,
> there might be such problems. And, it's a 2.2.x kernel I'm running,
> 2.4.x is not stable enough yet (ever?) on smp sun4m.
> 
> Cheers,
> 
> /ChJ
> 
> 
> 
> This was on a Debian Woody (test release) sun4m system using
> 
> binutils                           2.12.90.0.1-1
> dejagnu                            1.4.2-1.1
> gcc                                2:2.95.4-14 (Debian prerelease)
> gcc-2.95			   1:2.95.4-5 (Debian prerelease)
> kernel-image-2.2.20-sun4dm-smp     9
> libc6                              2.2.5-3 (now libc6-2.2.5-4)
> 
> 
> 
> 
> 
> 

gcc-3.1 2002-04-03 libjava failures on sparc-linux?

[Christian Jönsson]

Hej Tom.

I am test building the gcc-3.1 prereleases on sparc-linux, n.b.,
debian, no more sparc support from redhat...

The results of the testsuite is getting better and better, but libjava
still has a lot of failures.

Could you perhaps elaborate a little on what you think might be the
causes behind these failures?

I know that the support for sparc32 in the linux kernel is lagging,
there might be such problems. And, it's a 2.2.x kernel I'm running,
2.4.x is not stable enough yet (ever?) on smp sun4m.

Cheers,

/ChJ



This was on a Debian Woody (test release) sun4m system using

binutils                           2.12.90.0.1-1
dejagnu                            1.4.2-1.1
gcc                                2:2.95.4-14 (Debian prerelease)
gcc-2.95			   1:2.95.4-5 (Debian prerelease)
kernel-image-2.2.20-sun4dm-smp     9
libc6                              2.2.5-3 (now libc6-2.2.5-4)