Re: java/6461: sparc-sun-solaris2.7 gcc-3.1 libjava testsuite failure in FileHandleGcTest

Re: java/6461: sparc-sun-solaris2.7 gcc-3.1 libjava testsuite failure in FileHandleGcTest

[davem]

Synopsis: sparc-sun-solaris2.7 gcc-3.1 libjava testsuite failure in FileHandleGcTest

State-Changed-From-To: open->feedback
State-Changed-By: davem
State-Changed-When: Fri May  3 15:47:45 2002
State-Changed-Why:
    You need to continue further in your GDB session.
    The SIGSEGV is a normal part of Boehm-GC initialization.
    This is a FAQ.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6461

java/6461: sparc-sun-solaris2.7 gcc-3.1 libjava testsuite failure in FileHandleGcTest

[ghazi]

>Number:         6461
>Category:       java
>Synopsis:       sparc-sun-solaris2.7 gcc-3.1 libjava testsuite failure in FileHandleGcTest
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 25 13:06:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Kaveh Ghazi
>Release:        gcc version 3.1 20020423 (prerelease)
>Organization:
>Environment:
sparc-sun-solaris2.7 native as/ld
>Description:
I get the following failures in the libjava testsuite, see:
http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00935.html
http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00934.html

FAIL: FileHandleGcTest execution from source compiled test
FAIL: FileHandleGcTest execution from bytecode->native test
FAIL: FileHandleGcTest -O execution from source compiled test
FAIL: FileHandleGcTest -O execution from bytecode->native test

Running the FileHandleGcTest executable left behind by the harness under gdb, I get:

Starting program: /teal/caip5/ghazi/gcc-testing/branch/build/sparc-sun-solaris2.7/libjava/testsuite/FileHandleGcTest
[New LWP    2        ]
[New LWP    3        ]

Program received signal SIGSEGV, Segmentation fault.
0xff041f90 in GC_find_limit (p=0xffbef674 "", up=1) at ../../../egcc-3.1-CVS20020424/boehm-gc/os_dep.c:642
642               GC_noop1((word)(*result));
(gdb) where
#0  0xff041f90 in GC_find_limit (p=0xffbef674 "", up=1) at ../../../egcc-3.1-CVS20020424/boehm-gc/os_dep.c:642
#1  0xff04201c in GC_get_stack_base () at ../../../egcc-3.1-CVS20020424/boehm-gc/os_dep.c:793
#2  0xff04047c in GC_init_inner () at ../../../egcc-3.1-CVS20020424/boehm-gc/misc.c:590
#3  0xff040090 in GC_init () at ../../../egcc-3.1-CVS20020424/boehm-gc/misc.c:455
#4  0xff036924 in GC_init_gcj_malloc (mp_index=0, mp=0xff02bf6c) at ../../../egcc-3.1-CVS20020424/boehm-gc/gcj_mlc.c:60
#5  0xff02ccc8 in _Z10_Jv_InitGCv () at ../../../egcc-3.1-CVS20020424/libjava/boehm.cc:465
#6  0xfee79654 in _Z16_Jv_CreateJavaVMPv () at ../../../egcc-3.1-CVS20020424/libjava/prims.cc:892
#7  0xfee79ae8 in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b (klass=0x21124, name=0x0, argc=1, argv=0xffbefa3c,
    is_jar=false) at ../../../egcc-3.1-CVS20020424/libjava/prims.cc:982
#8  0x10c6c in main (argc=0, argv=0x1) at /var/tmp/ccLMCl8b.i:11
(gdb) p result
$1 = 0xffbf0000 <Address 0xffbf0000 out of bounds>
(gdb) 

This appears to be the same symptoms arising from PR6459 so it may be a duplicate.  Please verify.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: