Re: java/1912: Segfault when handling segfault = infinite recursion

Re: java/1912: Segfault when handling segfault = infinite recursion

[Nathanael Nerode]

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

>From neroden@twcny.rr.com  Mon Jan 13 01:02:33 2003
From: Nathanael Nerode <neroden@twcny.rr.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
   paul@dawa.demon.co.uk, java-prs@gcc.gnu.org
Cc:  
Subject: Re: java/1912: Segfault when handling segfault = infinite recursion
Date: Sat, 11 Jan 2003 18:10:33 -0500

 This is a very old bug.  Can the infinite recursion still be reproduced by 
 someone (the submitter?) or should we assume it's fixed and close it?
 
 --Nathanael

Re: java/1912: Segfault when handling segfault = infinite recursion

[Tom Tromey]

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

>From tromey@redhat.com  Mon Jan 13 01:05:39 2003
From: Tom Tromey <tromey@redhat.com>
To: neroden@twcny.rr.com
Cc: GNATS Filer <gcc-gnats@gcc.gnu.org>
Subject: Re: java/1912: Segfault when handling segfault = infinite recursion
Date: 12 Jan 2003 16:48:37 -0700

 >>>>> "Nathanael" == Nathanael Nerode <neroden@twcny.rr.com> writes:
 
 Nathanael> This is a very old bug.  Can the infinite recursion still
 Nathanael> be reproduced by someone (the submitter?) or should we
 Nathanael> assume it's fixed and close it?
 
 I believe if this happens it still causes problems in the runtime.
 Please don't close this report for the time being.
 
 Tom

Re: java/1912: Segfault when handling segfault = infinite recursion

[Andrew Haley]

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

From: Andrew Haley <aph@redhat.com>
To: tromey@redhat.com
Cc: paul@dawa.demon.co.uk, gcc-gnats@gcc.gnu.org
Subject: Re: java/1912: Segfault when handling segfault = infinite recursion
Date: Thu, 8 Feb 2001 17:44:29 +0000 (GMT)

 Tom Tromey writes:
  > >>>>> "Paul" == paul  <paul@dawa.demon.co.uk> writes:
  > 
  > Paul> #2  0x4018966a in _Jv_type_matcher (info=0x83dcde8, match_info=0xffffffff, 
  > Paul>     exception_table=0x8392d64) at ../../../gcc/libjava/exception.cc:62
  > 
  > I'm wondering if this is the same exception handling problem someone
  > reported a few days ago.
  > 
  > Andrew?
 
 It certainly could be.  I've no idea what the problem was, though.
 
 Andrew.
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1862
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010218113600.5436.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01435.html
Content-length: 517

The following reply was made to PR c++/1862; it has been noted by GNATS.

From: neil@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, khuang@sympatico.ca, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1862
Date: 18 Feb 2001 11:26:01 -0000

 Synopsis: Segmentation fault caused by compiler generated exit code
 
 State-Changed-From-To: open->closed
 State-Changed-By: neil
 State-Changed-When: Sun Feb 18 03:26:00 2001
 State-Changed-Why:
     Fixed for 3.0.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1862&database=gcc

Re: java/1912: Segfault when handling segfault = infinite recursion

[Paul Flinders]

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

From: Paul Flinders <paul@dawa.demon.co.uk>
To: tromey@redhat.com
Cc: paul@dawa.demon.co.uk, gcc-gnats@gcc.gnu.org
Subject: Re: java/1912: Segfault when handling segfault = infinite recursion
Date: Thu, 8 Feb 2001 21:58:23 +0000 (GMT)

 Tom Tromey writes:
  > >>>>> "Paul" == paul  <paul@dawa.demon.co.uk> writes:
  > 
  > Paul> #2  0x4018966a in _Jv_type_matcher (info=0x83dcde8, match_info=0xffffffff, 
  > Paul>     exception_table=0x8392d64) at ../../../gcc/libjava/exception.cc:62
  > 
  > I'm wondering if this is the same exception handling problem someone
  > reported a few days ago.
  > 
  > Andrew?
 
 It definately looks similar.
 
 I was able to do a little more debugging than Jeff - I think that the
 problem is that some of the exception table entries have match_info
 fields which are 0xffffffff. I haven't traced it back farther than
 that as I don't actually understand the code which produces
 __EXCEPTION_TABLE__, not the relationship of that to the table that
 find_exception_handler is scanning.
>From rodrigc@mediaone.net Sun Apr 01 00:00:00 2001
From: Craig Rodrigues <rodrigc@mediaone.net>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1709
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010224211600.30802.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01701.html
Content-length: 507

The following reply was made to PR c++/1709; it has been noted by GNATS.

From: Craig Rodrigues <rodrigc@mediaone.net>
To: rodrigc@mediaone.net, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1709
Date: Sat, 24 Feb 2001 16:05:54 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1709&database=gcc
 
 Please close this.
 I just tested with:
 gcc version 3.0 20010223 (prerelease)
 
 and it now works.
 
 --
 Craig Rodrigues
 http://www.gis.net/~craigr
 rodrigc@mediaone.net
 
 
 

java/1912: Segfault when handling segfault = infinite recursion

[paul]

>Number:         1912
>Category:       java
>Synopsis:       Segfault when handling segfault = infinite recursion
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 08 07:46:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     paul@dawa.demon.co.uk
>Release:        gcc version 2.97 20010208 (experimental)
>Organization:
>Environment:
RedHat Linux 7.0 x86
>Description:
JDMK's mibgen segfaulted due to a null java class pointer (this
is itself probably a gcj bug, since the same code works
in both Sun's and IBM's JDK). It the went into infinite recurion
as FindClassInCache segfaulted during the handling of the segfault.

The problem seems to be cause by an exception table entry
with a match_info field which is -1 which caused FindClass
to get called with a value of 0xfffffffe for "name".

Program received signal SIGSEGV, Segmentation fault.
_Jv_FindClassInCache(_Jv_Utf8Const*, java::lang::ClassLoader*) (
    name=0xfffffffe, loader=0x0)
    at ../../../gcc/libjava/java/lang/natClassLoader.cc:337
337	  jint hash = HASH_UTF (name);

(gdb) bt
#0  _Jv_FindClassInCache(_Jv_Utf8Const*, java::lang::ClassLoader*) (
    name=0xfffffffe, loader=0x0)
    at ../../../gcc/libjava/java/lang/natClassLoader.cc:337
#1  0x4019afc1 in _Jv_FindClass(_Jv_Utf8Const*, java::lang::ClassLoader*) (
    name=0xfffffffe, loader=0x0)
    at ../../../gcc/libjava/java/lang/natClassLoader.cc:460
#2  0x4018966a in _Jv_type_matcher (info=0x83dcde8, match_info=0xffffffff, 
    exception_table=0x8392d64) at ../../../gcc/libjava/exception.cc:62
#3  0x082531a1 in find_exception_handler (pc=0x81e8a2b, table=0x8392d64, 
    eh_info=0x83dcde8, rethrow=0, cleanup=0xbfffeb3c)
#4  0x082536fa in throw_helper (eh=0x8398f60, pc=0x81e8a2c, 
    my_udata=0xbfffedb0, offset_p=0xbfffedac)
#5  0x082537ea in __throw ()
#6  0x401897ba in _Jv_Throw (value=0x83b1fe0)
    at ../../../gcc/libjava/exception.cc:160
#7  0x081e8a2d in com.sun.jdmk.tools.mibgen.Parser.Mibs(com.sun.jdmk.tools.mibgen.ModulesHandler) (this=0x8435bd0, ARG_1=0x8413018)
    at com/sun/jdmk/tools/mibgen/Parser.java:49
#8  0x0819456f in com.sun.jdmk.tools.MibGen.doCompile() (this=0x83f2268)
    at com/sun/jdmk/tools/MibGen.java:265
#9  0x08195e5b in com.sun.jdmk.tools.MibGen.startCompile(java.lang.String[]) (
    this=0x83f2268, ARG_1=0x83d1f00) at com/sun/jdmk/tools/MibGen.java:499
#10 0x0819404f in com.sun.jdmk.tools.MibGen.compile(java.lang.String[]) (
    ARG_1=0x83d1f00) at com/sun/jdmk/tools/MibGen.java:484
#11 0x0819500b in com.sun.jdmk.tools.MibGen.main(java.lang.String[]) (
    ARG_1=0x83d1f00) at com/sun/jdmk/tools/MibGen.java:459
#12 0x401964db in gnu::gcj::runtime::FirstThread::run() (this=0x83b4ed0)
    at ../../../gcc/libjava/gnu/gcj/runtime/natFirstThread.cc:146
#13 0x401a0bcb in java::lang::Thread::run_(java::lang::Object*) (obj=0x83b4ed0)
    at ../../../gcc/libjava/java/lang/natThread.cc:276
#14 0x402bc35a in _Jv_ThreadStart(java::lang::Thread*, int*, void (*)(java::lang::Thread*)) (thread=0x83b4ed0, 
    meth=0x401a0a20 <java::lang::Thread::run_(java::lang::Object*)>)
    at ../../../gcc/libjava/no-threads.cc:28
#15 0x401a0cdf in java::lang::Thread::start() (this=0x83b4ed0)
    at ../../../gcc/libjava/java/lang/natThread.cc:307
#16 0x40180ff2 in JvRunMain (klass=0x82ca7a0, argc=37, argv=0xbffff1c4)
    at ../../../gcc/libjava/prims.cc:848
#17 0x082525e3 in main (argc=37, argv=0xbffff1c4) at /tmp/cce3lA2gmain.i:11
#18 0x404bbe51 in __libc_start_main (main=0x82525c0 <main>, argc=37, 
    ubp_av=0xbffff1c4, init=0x8053e68 <_init>, fini=0x8254d5c <_fini>, 
    rtld_fini=0x4000e264 <_dl_fini>, stack_end=0xbffff1bc)
    at ../sysdeps/generic/libc-start.c:111
>How-To-Repeat:
Difficult - I can't reproduce this easily in a small
test case :(
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From lerdsuwa@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: lerdsuwa@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/686
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010211120601.1144.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01129.html
Content-length: 551

The following reply was made to PR c++/686; it has been noted by GNATS.

From: lerdsuwa@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, jsvitak@yahoo.com, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/686
Date: 11 Feb 2001 11:58:52 -0000

 Synopsis: Internal error in g++ compilation
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: lerdsuwa
 State-Changed-When: Sun Feb 11 03:58:52 2001
 State-Changed-Why:
     Fixed.  The current CVS version no longer ICE after syntax error.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=686&database=gcc