JDK-4139586 : Unhandled Exception in java.exe (SYMCJIT.DLL): 0xC0000005: Access Violation
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jit_symantec
  • Affected Version: 1.1.5,1.1.6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_95,windows_nt
  • CPU: x86
  • Submitted: 1998-05-18
  • Updated: 1998-08-14
  • Resolved: 1998-08-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.1.6 1.1.6Fixed 1.2.0Fixed
Related Reports
Relates :  
Description
tim.bell@Eng 1998-06-03
New description & test case added.  Old description may be found
at the bottom.

ThreadTest runs indefinitely if started "java -nojit ThreadTest"

If started "java ThreadTest", a pop-up announces:

    The instruction at "0x01f1d689" referenced memory at
    "0x00000118"  The memory could not be "read"

Launching the debugger adds:
    Unhandled exception in java.exe (SYMCJIT.DLL) 0xC0000005: Access Violation


//Begin ThreadTest.java
/*
 * A background thread with certain do/while loop
 * constructs causes the JRE116 JIT VM to blow up.
 *
 * Here is the code (works fine under Solaris and NT with -nojit)
 *
 * --------------------------------------
 *
 * package arbdesk.test;
 */

import java.lang.Thread;

/**
* Test thread operation
*/
public final class ThreadTest implements Runnable, Biteable {
    /** Thread to handle incoming data from the server */
    private Thread receiver = null;

    /** Thread to send "ping" messages */
    private Watchdog keepTalking = null;

    /**
    * Constructor
    */
    public ThreadTest () {
	// Start the receiver thread
	receiver = new Thread(this);
	receiver.start();

	// Start the watchdog threads.
	// Set their priorities in the order of severity of the situations
	// that they are expected to handle.
	keepTalking = new Watchdog(this);
	keepTalking.setPriority(receiver.getPriority() + 1);
	debug("Threads started");
    }

    /**
    * runnable method for the receiver thread
    */
    public void run() {
	debug("run()");
	while (true) {

	    try {
		Thread.currentThread().sleep(1000);
		debug("run() finished sleeping");
	    }
	    catch(Exception ex) {
		ex.printStackTrace();
	    }

	}
    }

    public void doBite() {
	debug("Bitten");
    }

    /**
    * Display a diagnostic message
    */
    private void debug(String msg) {
	System.out.println(getClass().getName() + ':' + msg);
    }

    /**
    * Test method
    */
    public static void main(String[] argv) {
	ThreadTest t = new ThreadTest ();
    }
}


/**
* Interface to be implemented by classes that need to know when a
* watchdog expires
*/
interface Biteable {
    public abstract void doBite();
}

class Watchdog extends Thread {
    protected int intervalMins;
    protected int timeout;
    protected boolean autoRestart;
    protected Biteable observer;

    public Watchdog (Biteable observer) {
	this.observer = observer;
	this.timeout = 1;
	this.autoRestart = true;
	start();
    }

    /**
     * The thread body.
     * Sleep for a minute at a time, decrementing the
     * expiry timeout counter.  If the counter reaches
     * zero, call back into the Biteable "doBite"
     * method.
     */
    public void run() {
	do {
	    /*
	     *** Comment out the loops below to modify the
	     *** failure behaviour! ***
	     */
	    while (timeout > 0) {
		try {
		    sleep(6 * 1000);// Do nothing for 6 seconds
		}
		catch(InterruptedException e) {
		}
		timeout = 0;
	    }
	    observer.doBite();
	    timeout = 1;
	} while (autoRestart);
    }
}
// EOF
//End ThreadTest.java

======================================================================

Name: tb29552			Date: 05/18/98


We have a number of JAVA/CORBA servers which we invoke simultaneously
in seperate VM's on a Win NT 4 machine using JDK 1.1.6 with the JIT switched
on.  We are also using Visibroker V3.2.

Upon starting up the servers we randomly encounter the following error in
one of the Virtual Machines:

Unhandled Exception in java.exe (SYMCJIT.DLL): 0xC0000005: Access Violation

Although the memory address may be different the disassembly is mostly
the same (it seems to be the same line every time) this is provided below:

01F566F9   push        edi
01F566FA   push        esi
01F566FB   and         esi,0FEh
01F566FE   mov         ebx,dword ptr [esi+1Ch]
01F56701   mov         esi,dword ptr [esi+2Ch]
01F56704   test        esi,esi
01F56706   je          01F567C1
01F5670C   push        eax
01F5670D   mov         eax,dword ptr [edi+10h]
01F56710   pop         edi

The next line is the problem...

01F56711   mov         eax,dword ptr [eax+4]

01F56714   test        eax,1Fh
01F56719   je          01F56722
01F5671B   mov         eax,[01F54C08]
01F56720   jmp         01F56724
01F56722   mov         eax,dword ptr [eax]
01F56724   push        eax
01F56725   mov         eax,dword ptr [ebx+0Ch]
01F56728   test        eax,eax
01F5672A   je          01F567B6
01F56730   mov         edx,dword ptr [eax]
01F56732   mov         ecx,dword ptr [eax+4]
01F56735   test        byte ptr [esp+4],1
01F5673A   je          01F56742

The bytecode we are running on this is mostly compiled to JDK
1.02 using the Visual J++ compiler.  The bug does not always
occur and does not effect the same server every time.

Can you shed any light on this problem?
(Review ID: 30168)

More problems even with the new Symantec JIT Version x3.00.050:
At Cadence we can reproduce this bug but the memory location is different.

The instruction at "0x01f42b6f" referenced memory at "0x00000014"
The memory could not be "Read"

nasser.nouri@Corp 1998-07-13

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2beta4 INTEGRATED IN: 1.1.6 1.2beta4
14-06-2004

WORK AROUND Name: tb29552 Date: 05/18/98 Turn the JIT off and take a performance hit! ====================================================================== tim.bell@Eng 1998-07-09 The workaround is to run JDK 1.1.6 without the JIT. For example: java -nojit <classname> jre -nojit <classname> javac -J-nojit abc.java appletviewer -J-nojit xyz.html Refer to this URL for the Windows version of the Tools Reference Pages: http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/java.html
11-06-2004

PUBLIC COMMENTS .
10-06-2004

EVALUATION This bug will be forwarded to Symantec for further investigation. deepa.viswanathan@eng 1998-05-19
19-05-1998