EXCEPTION_ACCESS_VIOLATION

I am getting the Access violation error message when I use JNI to pass data to a COM client developed with C++. Through using message boxes as break points in the C++ source code, I can see that the native code works fine. It uses the data sent from the Java end, calls and manipulates the COM components (i.e. it displays the windows I expect to see, calls the print dialog, accepts user input and prints my document). Then control is returned to the VM. This is when the error shows up. When I commented out the portion that uses the COM component the error does not occur. I am using VM 1.5.I have used the -Xcheck:jni option and nothing is reported back.

Please help if you can.

# An unexpected error has been detected by HotSpot Virtual Machine:

#

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0308492e, pid=964, tid=2164

#

# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing)

# Problematic frame:

# C 0x0308492e

#

T H R E A D

Current thread (0x000369b0): JavaThread "main" [_thread_in_native, id=2164]

siginfo: ExceptionCode=0xc0000005, reading address 0x0308492e

Registers:

EAX=0x7ffdf000, EBX=0x00000000, ECX=0x00000000, EDX=0x0000006e

ESP=0x0007f830, EBP=0x0007f858, ESI=0x0308492e, EDI=0x0007f894

EIP=0x0308492e, EFLAGS=0x00010202

Top of Stack: (sp=0x0007f830)

0x0007f830:77d48734 00070318 00000376 00000000

0x0007f840:00000000 0308492e dcbaabcd 00000000

0x0007f850:0007f894 0308492e 0007f8c0 77d48816

0x0007f860:0308492e 00070318 00000376 00000000

0x0007f870:00000000 00000376 0059de50 0059de64

0x0007f880:00000014 00000001 00000000 00000000

0x0007f890:00000010 00000000 001932cc 00000001

0x0007f8a0:00000000 00000000 0007f874 0007f454

Instructions: (pc=0x0308492e)

0x0308491e:

[error occurred during error reporting, step 100, id 0xc0000005]

Stack: [0x00040000,0x00080000), sp=0x0007f830, free space=254k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C 0x0308492e

C [USER32.dll+0x8816]

C [USER32.dll+0xb89b]

C [USER32.dll+0x1f3e3]

C [sfmisRABCOM.dll+0x295d0]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j sfmisRAB.PreviewCard(LRAB_Badges;)V+0

j sfmisRAB.main([Ljava/lang/String;)V+18

v ~StubRoutines::call_stub

P R O C E S S

Java Threads: ( => current thread )

0x00a69520 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3604]

0x00a680e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=4008]

0x00a67bf8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=3752]

0x00a623c8 JavaThread "Finalizer" daemon [_thread_blocked, id=2132]

0x00a60ef8 JavaThread "Reference Handler" daemon [_thread_blocked, id=2176]

=>0x000369b0 JavaThread "main" [_thread_in_native, id=2164]

Other Threads:

0x0003fc58 VMThread [id=3768]

0x00a6a740 WatcherThread [id=2556]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap

def new generationtotal 576K, used 239K [0x22bd0000, 0x22c70000, 0x230b0000)

eden space 512K, 46% used [0x22bd0000, 0x22c0bf28, 0x22c50000)

from space 64K,0% used [0x22c50000, 0x22c50000, 0x22c60000)

tospace 64K,0% used [0x22c60000, 0x22c60000, 0x22c70000)

tenured generationtotal 1408K, used 0K [0x230b0000, 0x23210000, 0x26bd0000)

the space 1408K,0% used [0x230b0000, 0x230b0000, 0x230b0200, 0x23210000)

compacting perm gen total 8192K, used 22K [0x26bd0000, 0x273d0000, 0x2abd0000)

the space 8192K,0% used [0x26bd0000, 0x26bd5830, 0x26bd5a00, 0x273d0000)

ro space 8192K, 63% used [0x2abd0000, 0x2b0db178, 0x2b0db200, 0x2b3d0000)

rw space 12288K, 46% used [0x2b3d0000, 0x2b969fa8, 0x2b96a000, 0x2bfd0000)

Dynamic libraries:

0x00400000 - 0x0040c000 C:\WINDOWS\system32\java.exe

0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll

0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll

0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll

0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll

0x77c10000 - 0x77c68000 C:\WINDOWS\system32\MSVCRT.dll

0x6d670000 - 0x6d804000 C:\Program Files\Java\jre1.5.0_06\bin\client\jvm.dll

0x77d40000 - 0x77dd0000 C:\WINDOWS\system32\USER32.dll

0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll

0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll

0x10000000 - 0x10011000 C:\WINDOWS\system32\AMINIT.dll

0x6d280000 - 0x6d288000 C:\Program Files\Java\jre1.5.0_06\bin\hpi.dll

0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL

0x6d640000 - 0x6d64c000 C:\Program Files\Java\jre1.5.0_06\bin\verify.dll

0x6d300000 - 0x6d31d000 C:\Program Files\Java\jre1.5.0_06\bin\java.dll

0x6d660000 - 0x6d66f000 C:\Program Files\Java\jre1.5.0_06\bin\zip.dll

0x02e90000 - 0x02eda000 C:\sfmis5_2_1\client\com\sfmisRAB\sfmisRABCOM.dll

0x73000000 - 0x73026000 C:\WINDOWS\system32\WINSPOOL.DRV

0x5d090000 - 0x5d12a000 C:\WINDOWS\system32\COMCTL32.dll

0x77f60000 - 0x77fd6000 C:\WINDOWS\system32\SHLWAPI.dll

0x774e0000 - 0x7761d000 C:\WINDOWS\system32\ole32.dll

0x77120000 - 0x771ac000 C:\WINDOWS\system32\OLEAUT32.dll

0x5ad70000 - 0x5ada8000 C:\WINDOWS\system32\uxtheme.dll

0x76fd0000 - 0x7704f000 C:\WINDOWS\system32\CLBCATQ.DLL

0x77050000 - 0x77115000 C:\WINDOWS\system32\COMRes.dll

0x77c00000 - 0x77c08000 C:\WINDOWS\system32\VERSION.dll

0x71ab0000 - 0x71ac7000 C:\WINDOWS\system32\WS2_32.dll

0x71aa0000 - 0x71aa8000 C:\WINDOWS\system32\WS2HELP.dll

0x5d360000 - 0x5d36e000 C:\WINDOWS\system32\MFC71ENU.DLL

0x773d0000 - 0x774d3000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll

0x04880000 - 0x04b45000 C:\WINDOWS\system32\xpsp2res.dll

0x745e0000 - 0x748a6000 C:\WINDOWS\system32\msi.dll

0x75e90000 - 0x75f40000 C:\WINDOWS\system32\SXS.DLL

[6211 byte] By [Kumbia] at [2007-11-26 20:18:25]
# 1

> I am getting the Access violation error message when

> I use JNI to pass data to a COM client developed with

> C++. Through using message boxes as break points in

> the C++ source code, I can see that the native code

> works fine.

Debuggers change the code that they are debugging. Thus a app that fails without a debugger might succeed with it.

Pointer bugs in C/C++ can cause the application to fail many, many lines after where the actual pointer problem occurred.

>...portion that uses the COM component the error does not occur.

Which not surprisingly strongly suggests that the problem is in the native code. You might start by verify that all JNI code has the proper error checks (including exception throws.)

jschella at 2007-7-10 0:42:02 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2
You can also run your application and add the option -Xcheck:jni to the java command line.This performs sanity checks on most JNI calls and will flag common errors. That may help narrow down the problem.
jxca at 2007-7-10 0:42:02 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 3

Thanks, as I noted in my description of the error I did use the -Xcheck:jni option and nothing is reported back.

I feel it is something to do with the smart pointer that is provided by the software package I am using. I have pinpointed the problem to where my application makes use of the call to CreateInstance() using this smart pointer. This is where the problem occurs. The strange occurence is that processing will continue with the application making use of the data brought in by the native method and returning values back to the Java end. Then the error shows up. This occurs even without any breakpoints in my application.

Kumbia at 2007-7-10 0:42:02 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 4

The problem occurs the same way with or without breakpoints (MessageBoxes) in my code.Without any message boxes in the application, the values sent are retrieved, processed and the result sent back by the native method before the error shows up. I even do a println in the Java code of the result sent back before the error shows up.

It appears that it is something about the creation of the COM component that is causing the JRE to fail. Interestingly, I have been running this appliction (same client code making use of COM components) for some time now using a C++ front end to pass the data with absolutely no problem. The only difference now is that I am using a Java front end and passing the data using JNI. As I wrote earlier, I have used the -Xcheck:jni option with no error reported. I have even use JRE 6 with the

-XX:-RelaxAccessControlCheck option. That does not help.

Kumbia at 2007-7-10 0:42:02 > top of Java-index,Java HotSpot Virtual Machine,Specifications...