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

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:

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

[Kaveh R. Ghazi]

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

From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: davem@gcc.gnu.org, davem@redhat.com, gcc-bugs@gcc.gnu.org,
        gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, java-prs@gcc.gnu.org,
        nobody@gcc.gnu.org, tromey@redhat.com
Cc:  
Subject: Re: java/6461: sparc-sun-solaris2.7 gcc-3.1 libjava testsuite failure in FileHandleGcTest
Date: Wed, 8 May 2002 16:24:50 -0400 (EDT)

 (gdb) cont
 Continuing.
 [New LWP    4        ]
 /proc open failed: too many open files
 
 Program received signal SIGABRT, Aborted.
 0xfebd9d88 in __sigprocmask () from /usr/lib/libthread.so.1
 (gdb) bt
 #0  0xfebd9d88 in __sigprocmask () from /usr/lib/libthread.so.1
 #1  0xfebcf3cc in _resetsig () from /usr/lib/libthread.so.1
 #2  0xfebceb88 in _sigon () from /usr/lib/libthread.so.1
 #3  0xfebd195c in _thrp_kill () from /usr/lib/libthread.so.1
 #4  0xfea395c0 in abort () from /usr/lib/libc.so.1
 #5  0xff041204 in GC_abort (msg=0xff11d9e8 "/proc open failed: too many open files")
     at ../../../egcc-3.1-CVS20020507/boehm-gc/misc.c:948
 #6  0xff046874 in stop_all_lwps () at ../../../egcc-3.1-CVS20020507/boehm-gc/solaris_threads.c:238
 #7  0xff047410 in GC_stop_world () at ../../../egcc-3.1-CVS20020507/boehm-gc/solaris_threads.c:401
 #8  0xff030b84 in GC_stopped_mark (stop_func=0xff02fe9c <GC_never_stop_func>)
     at ../../../egcc-3.1-CVS20020507/boehm-gc/alloc.c:449
 #9  0xff030888 in GC_try_to_collect_inner (stop_func=0xff02fe9c <GC_never_stop_func>)
     at ../../../egcc-3.1-CVS20020507/boehm-gc/alloc.c:350
 #10 0xff031610 in GC_try_to_collect (stop_func=0xff02fe9c <GC_never_stop_func>)
     at ../../../egcc-3.1-CVS20020507/boehm-gc/alloc.c:735
 #11 0xff031680 in GC_gcollect () at ../../../egcc-3.1-CVS20020507/boehm-gc/alloc.c:746
 #12 0xfeeae818 in _ZN4java4lang6System2gcEv () at ../../../egcc-3.1-CVS20020507/libjava/java/lang/System.java:129
 #13 0xfee89c44 in _ZN4java2io14FileDescriptor4openEPNS_4lang6StringEi (this=<incomplete type>, path=0x1b6, jflags=1)
     at java/io/natFileDescriptor.cc:112
 #14 0xfeeb9d80 in _ZN4java2io14FileDescriptorC1EPNS_4lang6StringEi (this=0x817e0, path=0x1b6, mode=1) at
     ../../../egcc-3.1-CVS20020507/libjava/java/io/FileDescriptor.java:60
 #15 0xfeeb9ea0 in _ZN4java2io15FileInputStreamC1EPNS_4lang6StringE (this=0x817f0, name=0x6e258) at
      ../../../egcc-3.1-CVS20020507/libjava/java/io/FileInputStream.java:31
 #16 0x10d24 in _ZN16FileHandleGcTest4mainEP6JArrayIPN4java4lang6StringEE () at FileHandleGcTest.java:9
 #17 0xfee88ee8 in _ZN3gnu3gcj7runtime11FirstThread9call_mainEv (this=0xac888) at
     ../../../egcc-3.1-CVS20020507/libjava/gnu/gcj/runtime/natFirstThread.cc:46
 #18 0xfee940e0 in _Z13_Jv_ThreadRunPN4java4lang6ThreadE (thread=0xac888) at
     ../../../egcc-3.1-CVS20020507/libjava/java/lang/natThread.cc:285
 #19 0xfee79c44 in _Z11_Jv_RunMainPN4java4lang5ClassEPKciPS4_b (klass=0x21124, name=0x0, argc=0, argv=0xffbef9d4,
     is_jar=false) at ../../../egcc-3.1-CVS20020507/libjava/prims.cc:1010

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