Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4495990
Votes 1
Synopsis VM crashes if a run method throws an expection in a finally block
Category hotspot:compiler1
Reported Against 1.3.1_07 , merlin-beta
Release Fixed 1.3.1_10
State 10-Fix Delivered, bug
Priority: 2-High
Related Bugs
Submit Date 24-AUG-2001
Description




java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

This also happens with JDK 1.3.1, 1.4.0-beta-b65.

VM crashes when running multi threaded application if a run method throws an
exception in a finally block.

A sample program that shows the problem follows:

package untitled30;

public class Application1 {
    boolean packFrame = false;

    /**Construct the application*/
    public Application1() {
    }
        
    void testThread(int size) {
        int i=0;
        while (i < size) {
            TT tt = new TT();
            tt.setLoop(i * 11);
            tt.start();
            i++;
        }
    }
    
    
    /**Main method*/
    public static void main(String[] args) {
        Application1 ap =  new Application1();
        
        ap.testThread(100);
    }
    
    
    class TT extends Thread {
    
    
            int loop=0;
            
            public void setLoop(int l) {
                loop = l;
            }
            
            public void run() {
                int j =0;
                try {
                    while (j < loop) {
                        if (j % 50 == 0)
                            System.out.println("I am " + this + " " + j);
                        j++;
                    }

                } catch (Exception e) {
                
	        } finally {
System.out.println (" i die " + this);
// the following throw can cause the VM to crash
                    try {
                        throw new Exception("Stack Cleanup");
                    } catch (Exception e) {
                    // Clean!
                    }
	        }
            }
    }
}



With JDK1.3.0:
----------

I am Thread[Thread-17,5,main] 150
 i die Thread[Thread-17,5,main]
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 43113F32554E54494D45110E4350500290
#
I am Thread[Thread-18,5,main] 0
I am Thread[Thread-18,5,main] 50
I am Thread[Thread-18,5,main] 100
I am Thread[Thread-18,5,main] 150
 i die Thread[Thread-18,5,main]
[error occured during error reporting]

abnormal program termination


With JDK1.3.1:
-------------

C:\>java Application1
 i die Thread[Thread-0,5,main]
I am Thread[Thread-1,5,main] 0
----------------------------------
----------------------------------
I am Thread[Thread-17,5,main] 100
I am Thread[Thread-17,5,main] 150
 i die Thread[Thread-17,5,main]
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 43113F32554E54494D45110E43505002D3
#
# Problematic Thread: prio=5 tid=0x777ad0 nid=0x138 runnable



With JDK1.4.0-beta-b65:
----------------------

C:\>java Application1
 i die Thread[Thread-0,5,main]
I am Thread[Thread-1,5,main] 0
-------------------------------
--------------------------------
I am Thread[Thread-36,5,main] 300
I am Thread[Thread-36,5,main] 350
 i die Thread[Thread-36,5,main]
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 43113F32554E54494D45110E4350500314
#
# Problematic Thread: prio=5 tid=0x00787ED0 nid=0x102 runnable
#

(Review ID: 130585) 
======================================================================
Work Around
N/A
Evaluation
 xxxxx@xxxxx  2001-09-10

Happens w/c1, but not with -Xint or -server on sparc.  Dies w/a SIGBUS in
c1-generated code.  Can reproduce with the following command line and latest main/baseline:

    java_g -Xcomp -XX:CompileOnly='Application1$TT.run' Application1

Stack trace:

 xxxxx@xxxxx  ( xxxxx@xxxxx ) signal BUS (invalid address alignment) in (unknown) at 0xf9cf09c4
0xf9cf09c4:     jmp     %o0
Current function is JavaCalls::call_helper
  353         StubRoutines::call_stub()(
dbx  xxxxx@xxxxx   xxxxx@xxxxx  23> where
current thread:  xxxxx@xxxxx 
  [1] 0xf9cf09c4(0x39, 0xf9cf0c7c, 0x0, 0xf9c2670c, 0x0, 0xf1581710), at 0xf9cf09c3
  [2] 0xf9cf0d28(0xf183e910, 0x145a80, 0x8, 0x0, 0xf1581b24, 0x10), at 0xf9cf0d27
  [3] 0xf9c00528(0xf1581898, 0xf1581bd0, 0xa, 0xf58eb6e8, 0xf9c0d0d0, 0xf1581b18), at 0xf9c00527
=>[4] JavaCalls::call_helper(result = 0xf1581bc8, m = 0xf1581a50, args = 0xf1581b0c, __the_thread__ = 0x145a80), line 353 in "javaCalls.cpp"
  [5] os::os_exception_wrapper(f = 0xfdb3aed8 = &JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*), value = 0xf1581bc8, method = 0xf1581a50, args = 0xf1581b0c, thread = 0x145a80), line 1854 in "os_solaris.cpp"
  [6] JavaCalls::call(result = 0xf1581bc8, method = CLASS, args = 0xf1581b0c, __the_thread__ = 0x145a80), line 290 in "javaCalls.cpp"
  [7] JavaCalls::call_virtual(result = 0xf1581bc8, spec_klass = CLASS, name = CLASS, signature = CLASS, args = 0xf1581b0c, __the_thread__ = 0x145a80), line 186 in "javaCalls.cpp"
  [8] JavaCalls::call_virtual(result = 0xf1581bc8, receiver = CLASS, spec_klass = CLASS, name = CLASS, signature = CLASS, __the_thread__ = 0x145a80), line 192 in "javaCalls.cpp"
  [9] thread_entry(thread = 0x145a80, __the_thread__ = 0x145a80), line 1733 in "jvm.cpp"
  [10] JavaThread::thread_main_inner(this = 0x145a80), line 1148 in "thread.cpp"
  [11] JavaThread::run(this = 0x145a80), line 1132 in "thread.cpp"
  [12] _start(data = 0x145a80), line 494 in "os_solaris.cpp"
dbx  xxxxx@xxxxx   xxxxx@xxxxx  24> frame 1
0xf9cf09c4:     jmp     %o0
dbx  xxxxx@xxxxx   xxxxx@xxxxx  25> print -fx $o0
dbx: warning: unknown language, 'ansic' assumed
$o0 = 0x39


--------------------------------------------------------

The GraphBuilder is optimizing Jsrs which do not end in (any) Ret into Gotos,
generating a fake bci instead of a real program counter as the effect of the
call to the subroutine. Because control flow changes due to exception throwing,
an unrelated block to the Jsr attempts to Ret to the bci. The solution is to remove this optimization and treat all Jsrs identically.

 xxxxx@xxxxx  2001-09-26


Fixed in Beta 3, most likely B83.

 xxxxx@xxxxx  2001-10-04
Comments
  
  Include a link with my name & email   

Submitted On 21-MAY-2002
ppavanrao
I developed a small Aplication and I still have the the 
same defect even though i removed all the try catch blocks 
within finally block.

ANy idea/workArounds for this ??



PLEASE NOTE: JDK6 is formerly known as Project Mustang