EXCEPTION_ACCESS_VIOLATION Jni Wrapper

Hi i have an EJB in jboss, it use IIOP to conect a c# client its working but some times it crash with the followin error message can some one help me:
# An unexpected error has been detected by HotSpot Virtual Machine:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10001a41, pid=4560, tid=5340
# Java VM: Java HotSpot(TM) Client VM (1.5.0_09-b03 mixed mode, sharing)
# Problematic frame:
# C [jniwrap.dll+0x1a41]
--------------- T H R E A D ---------------
Current thread (0x02a175e8): JavaThread "AppMon" daemon [_thread_in_native, id=5340]
siginfo: ExceptionCode=0xc0000005, reading address 0x02cf7000
Registers:
EAX=0x039af6c0, EBX=0x00000004, ECX=0x02cf7000, EDX=0x00000002
ESP=0x039af68c, EBP=0x039af824, ESI=0x100080ee, EDI=0x039af6eb
EIP=0x10001a41, EFLAGS=0x00010202
Top of Stack: (sp=0x039af68c)
0x039af68c: 039af6c0 00000010 02a176a8 02cf6ff0
0x039af69c: 00000009 02cf7000 00000001 7c8302b3
0x039af6ac: 039af274 039af360 7c82f9c1 c0000005
0x039af6bc: 7c82f9dd 00636364 30003030 02a17600
0x039af6cc: 7c831fb2 7c831fe4 66366636 30303061
0x039af6dc: 372c302c 30373733 63642c30 00002c63
0x039af6ec: 00000000 00000000 00000000 00000000
0x039af6fc: 00000000 00000000 00000000 00000000
Instructions: (pc=0x10001a41)
0x10001a31: a4 6a 10 8d 85 9c fe ff ff 50 8b 8d 7c fe ff ff
0x10001a41: 8b 11 52 ff 15 40 60 00 10 83 c4 0c 8d 95 b0 fe
Stack: [0x03970000,0x039b0000), sp=0x039af68c, free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [jniwrap.dll+0x1a41]
C [jniwrap.dll+0x1d30]
J com.jniwrapper.Function.invokeCFunc(IIB[BII[II)I
J com.jniwrapper.FunctionCall.a(ZIIIIBLcom/jniwrapper/Parameter;[Lcom/jniwrapper/Parameter;)J
J com.jniwrapper.Function.invoke(Lcom/jniwrapper/Parameter;[Lcom/jniwrapper/Parameter;)J
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j com.jniwrapper.Function.invoke(Lcom/jniwrapper/Parameter;Lcom/jniwrapper/Parameter;Lcom/jniwrapper/Parameter;)J+14
j com.jniwrapper.win32.ui.Wnd.getAllWindows()Ljava/util/List;+42
j com.adobe.appmon.AppMon.getAllWindows()Ljava/util/List;+0
j com.adobe.appmon.AppMon.processAllDialogs()Z+1
j com.adobe.appmon.AppMon.loopAllDialogs()Z+35
j com.adobe.appmon.AppMon.loopAppMon()V+65
j com.adobe.appmon.AppMon.segueToLoop()V+98
j com.adobe.appmon.AppMon.run()V+99
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [jvm.dll+0x86e84]
V [jvm.dll+0xddead]
V [jvm.dll+0x86d55]
V [jvm.dll+0x86ab2]
V [jvm.dll+0xa16b2]
V [jvm.dll+0x10f4ac]
V [jvm.dll+0x10f47a]
C [MSVCRT.dll+0x2b530]
C [kernel32.dll+0x2608b]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J com.jniwrapper.Function.invokeCFunc(IIB[BII[II)I
J com.jniwrapper.FunctionCall.a(ZIIIIBLcom/jniwrapper/Parameter;[Lcom/jniwrapper/Parameter;)J
J com.jniwrapper.Function.invoke(Lcom/jniwrapper/Parameter;[Lcom/jniwrapper/Parameter;)J
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j com.jniwrapper.Function.invoke(Lcom/jniwrapper/Parameter;Lcom/jniwrapper/Parameter;Lcom/jniwrapper/Parameter;)J+14
j com.jniwrapper.win32.ui.Wnd.getAllWindows()Ljava/util/List;+42
j com.adobe.appmon.AppMon.getAllWindows()Ljava/util/List;+0
j com.adobe.appmon.AppMon.processAllDialogs()Z+1
j com.adobe.appmon.AppMon.loopAllDialogs()Z+35
j com.adobe.appmon.AppMon.loopAppMon()V+65
j com.adobe.appmon.AppMon.segueToLoop()V+98
j com.adobe.appmon.AppMon.run()V+99
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
=>0x02a175e8 JavaThread "AppMon" daemon [_thread_in_native, id=5340]
0x02994fc0 JavaThread "PDFExportAcrobat" daemon [_thread_blocked, id=5140]
0x02cad4f8 JavaThread "RequestProcessor-16" daemon [_thread_blocked, id=5652]
0x02d06bd8 JavaThread "RequestProcessor-15" daemon [_thread_blocked, id=5784]
0x02b0b5a8 JavaThread "RequestController-9" daemon [_thread_blocked, id=3608]
0x02c668f8 JavaThread "AWT-Windows" daemon [_thread_in_native, id=516]
0x02a5e910 JavaThread "Thread-11" daemon [_thread_in_native, id=3740]
0x02a36628 JavaThread "Thread-10" daemon [_thread_in_native, id=4192]
0x02b0bd68 JavaThread "RequestProcessor-2" daemon [_thread_blocked, id=2180]
0x02b0bb48 JavaThread "RequestProcessor-1" daemon [_thread_blocked, id=4148]
0x029e6958 JavaThread "Thread-8" daemon [_thread_in_native, id=2732]
0x02a1c8b8 JavaThread "stdInMonitor" [_thread_in_native, id=6072]
0x02a19560 JavaThread "com.jniwrapper.NativeResourceCollector" daemon [_thread_blocked, id=5256]
0x029dfed0 JavaThread "Thread-6" daemon [_thread_in_native, id=5816]
0x02c60ac8 JavaThread "RequestController-2" daemon [_thread_blocked, id=600]
0x02d29be0 JavaThread "JacORB Listener Thread on port 3620" daemon [_thread_in_native, id=5396]
0x02a60218 JavaThread "RequestController-1" daemon [_thread_blocked, id=4996]
0x029aee40 JavaThread "Thread-3" [_thread_blocked, id=5184]
0x006f36b0 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=6116]
0x006f23c0 JavaThread "CompilerThread0" daemon [_thread_blocked, id=5524]
0x006f16d8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2240]
0x006eb7f8 JavaThread "Finalizer" daemon [_thread_blocked, id=4844]
0x006c2b48 JavaThread "Reference Handler" daemon [_thread_blocked, id=444]
0x003c8258 JavaThread "main" [_thread_blocked, id=5004]
Other Threads:
0x006c0180 VMThread [id=4464]
0x006f1320 WatcherThread [id=4824]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 576K, used 102K [0x25660000, 0x25700000, 0x257e0000)
eden space 512K, 7% used [0x25660000, 0x25669930, 0x256e0000)
from space 64K, 99% used [0x256f0000, 0x256fffd8, 0x25700000)
to space 64K, 0% used [0x256e0000, 0x256e0000, 0x256f0000)
tenured generation total 4560K, used 2853K [0x257e0000, 0x25c54000, 0x26a60000)
the space 4560K, 62% used [0x257e0000, 0x25aa96e8, 0x25aa9800, 0x25c54000)
compacting perm gen total 8192K, used 2813K [0x26a60000, 0x27260000, 0x2aa60000)
the space 8192K, 34% used [0x26a60000, 0x26d1f480, 0x26d1f600, 0x27260000)
ro space 8192K, 67% used [0x2aa60000, 0x2afbe5d8, 0x2afbe600, 0x2b260000)
rw space 12288K, 47% used [0x2b260000, 0x2b8087f0, 0x2b808800, 0x2be60000)
Dynamic libraries:
0x00400000 - 0x0040d000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\javaw.exe
0x7c800000 - 0x7c8c0000 C:\WINDOWS\system32\ntdll.dll
0x77e40000 - 0x77f42000 C:\WINDOWS\system32\kernel32.dll
0x77f50000 - 0x77fec000 C:\WINDOWS\system32\ADVAPI32.dll
0x77c50000 - 0x77cef000 C:\WINDOWS\system32\RPCRT4.dll
0x77380000 - 0x77412000 C:\WINDOWS\system32\USER32.dll
0x77c00000 - 0x77c48000 C:\WINDOWS\system32\GDI32.dll
0x77ba0000 - 0x77bfa000 C:\WINDOWS\system32\MSVCRT.dll
0x6d730000 - 0x6d8cb000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\client\jvm.dll
0x76aa0000 - 0x76acd000 C:\WINDOWS\system32\WINMM.dll
0x6d2f0000 - 0x6d2f8000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\hpi.dll
0x76b70000 - 0x76b7b000 C:\WINDOWS\system32\PSAPI.DLL
0x6d700000 - 0x6d70c000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\verify.dll
0x6d370000 - 0x6d38d000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\java.dll
0x6d720000 - 0x6d72f000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\zip.dll
0x6d530000 - 0x6d543000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\net.dll
0x71c00000 - 0x71c17000 C:\WINDOWS\system32\WS2_32.dll
0x71bf0000 - 0x71bf8000 C:\WINDOWS\system32\WS2HELP.dll
0x55600000 - 0x5561d000 C:\Program Files\Microsoft Firewall Client\wspwsp.dll
0x76cf0000 - 0x76d0a000 C:\WINDOWS\system32\iphlpapi.dll
0x71b20000 - 0x71b61000 C:\WINDOWS\system32\mswsock.dll
0x5f270000 - 0x5f2c9000 C:\WINDOWS\system32\hnetcfg.dll
0x71ae0000 - 0x71ae8000 C:\WINDOWS\System32\wshtcpip.dll
0x76ed0000 - 0x76eff000 C:\WINDOWS\system32\DNSAPI.dll
0x76f70000 - 0x76f77000 C:\WINDOWS\System32\winrnr.dll
0x76f10000 - 0x76f3e000 C:\WINDOWS\system32\WLDAP32.dll
0x76f80000 - 0x76f88000 C:\WINDOWS\system32\rasadhlp.dll
0x10000000 - 0x1000b000 C:\jboss-4.0.4.GA\server\all\svcnative\PDFExportConverterService\bin\dll\jniwrap.dll
0x6d070000 - 0x6d1d9000 C:\Program Files\Java\jdk1.5.0_09\jre\bin\awt.dll
0x73070000 - 0x73097000 C:\WINDOWS\system32\WINSPOOL.DRV
0x76290000 - 0x762ad000 C:\WINDOWS\system32\IMM32.dll
0x77670000 - 0x777a4000 C:\WINDOWS\system32\ole32.dll
0x73860000 - 0x738ac000 C:\WINDOWS\system32\ddraw.dll
0x73b30000 - 0x73b36000 C:\WINDOWS\system32\DCIMAN32.dll
0x77d00000 - 0x77d8c000 C:\WINDOWS\system32\oleaut32.dll
0x777b0000 - 0x77833000 C:\WINDOWS\system32\CLBCatQ.DLL
0x77010000 - 0x770d6000 C:\WINDOWS\system32\COMRes.dll
0x77b90000 - 0x77b98000 C:\WINDOWS\system32\VERSION.dll
0x03610000 - 0x038d5000 C:\WINDOWS\system32\xpsp2res.dll
0x75da0000 - 0x75e5c000 C:\WINDOWS\system32\SXS.DLL
0x03590000 - 0x03595000 C:\jboss-4.0.4.GA\server\all\svcnative\PDFExportConverterService\bin\dll\procinfo.dll
0x7c3a0000 - 0x7c41b000 C:\WINDOWS\system32\MSVCP71.dll
0x7c340000 - 0x7c396000 C:\WINDOWS\system32\MSVCR71.dll
VM Arguments:
jvm_args: -Xmx20M
java_command: com.adobe.native2pdf.bmc.PDFExportConverterServer -IOR IOR:000000000000002249444C3A636F6D2F61646F62652F736572766963652F4D616E616765723A312E300000000000000200000000000000D8000102000000000B31302E312E31382E323500000DC80000000000134A426F73732F42522D312F010000000000000000000000050000000000000008000000004A414300000000010000001C000000000001000100000001050100010001010900000001050100010000002100000050000000000000000100000000000000240000001E0000007E00000000000000010000000B31302E312E31382E323500000DC90000000000000000000000000000000000000000000000000000000000000000002000000004000000000000001F0000000400000003000000010000002000000000000000020000002000000004000000000000001F0000000400000003 -AppServer jboss
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=C:\Program Files\Java\jdk1.5.0_07
PATH=C:\jboss-4.0.4.GA\server\all\svcnative\PDFExportConverterService\bin\dll;C:\jboss-4.0.4.GA\server\all\svcnative\ServicesNatives2\lib;C:\Program Files\Adobe\Document Server 6.0\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Dell\SysMgt\oma\bin;C:\Program Files\Microsoft SQL Server\80\Tools\BINN;C:\Program Files\Common Files\Adobe\AGL;C:\Program Files\Java\jdk1.5.0_09\bin;C:\apache-ant-1.6.5\bin;C:\jboss-4.0.4.GA\bin
USERNAME=penuelas
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows Server 2003 family Build 3790 Service Pack 1
CPU:total 4 (cores per cpu 1, threads per core 2) family 15 model 4 stepping 1, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ht
Memory: 4k page, physical 2096400k(509568k free), swap 4038616k(2399784k free)
vm_info: Java HotSpot(TM) Client VM (1.5.0_09-b03) for windows-x86, built on Oct 12 2006 01:20:10 by "java_re" with MS VC++ 6.0
hope someone can help me
sorry for my english

See Library for .NET Framework v.1.1
http://www.simtel.net/product.php[id]95126[SiteID]simtel.net
and Add-In
http://www.simtel.net/product.php[id]98493[SiteID]simtel.net
or
Library for .NET Framework v.2.0
http://www.simtel.net/product.php[id]98653[SiteID]simtel.net

Similar Messages

Tool for generating JNI Wrapper DLL

Hi,
In my project I need to access methods from third party C++ DLL using JNI.
For that I will have to write a JNI Wrapper DLL.
I am a java programmer and have no idea about C++ programming and creating DLLs.
Is there any tool available that can generate wrapper DLL for me out of that third party DLL?
Thanks
-Pragati

Hi
I am working on JNI Implementaion.
Please help me out in generating the DLL file using VC++.
I am able to successfully compile the file and able to generate the lib files but it is not generating the DLL file.
Can you please check this once.
Displaying the following message.
--------------------Configuration: ikmp2lib - Win32 Release--------------------
Compiling...
ikmp2Lib1.c
IKMP_lib.c
Linking...
Microsoft (R) Incremental Linker Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib D:\DecevalJNI\ikmp2lib\Release\ikmp2Lib1.obj D:\DecevalJNI\ikmp2lib\Release\IKMP_lib.obj D:\DecevalJNI\ikmp2
lib\Release\IKMP_callback.obj c:\forte\install\lib\qqsm.lib c:\forte\install\lib\qqfo.lib c:\forte\install\lib\qqdo.lib c:\forte\install\lib\qqcm.lib c:\forte\install\lib\qqkn.lib kmpapi32.lib OLDNAMES.LIB OLDNAMES.LIB KERNEL32.LIB USER32.LIB GDI32.
LIB WINSPOOL.LIB COMDLG32.LIB SHELL32.LIB WSOCK32.LIB NETAPI32.LIB WINMM.LIB ADVAPI32.LIB
Creating library ikmp2Lib1.lib and object ikmp2Lib1.exp
ikmp2lib.dll - 0 error(s), 0 warning(s)
Thanks and Regards
Chatrapathi

How to use the dll created by c++ but not write a jni wrapper around

how to use the dll created by c++ but not write a jni wrapper around through a java program. now I can't access that dll like this directly from java.

Your question is unclear. (You haven't said what dll you are talking about.)
But:
If you are talking about an existing dll, then the only alternative to writing a wrapper is to use one of the wrapper generators floating around. Do a search on JACE.
If you are talking about a dll you are writing, then run jah and get the interface to match java right away; then you won't have to write a wrapper.

Calling a third-party library from JNI-enabled C++ code

Hi everyone,
I have some existing C++ application code that extracts data from a file in a special format (HDF5). This code uses a static library (third party) to decode the file format. I would like to wrap this application code in a JNI wrapper so that I can call the code from Java. So I have a situation like this:
Java front end -> application code (C++) -> static library (C++)
I have compiled JNI headers and modified the application code accordingly. I created a shared library by bundling the application code together with the static library (using gcc 3.2.2 on Red Hat Linux 9):
g++ -shared hdf5_jni.cc -o libhdf5_jni.so -I<include path> -L<static library path> -lhdf5
(the <static library path> contains the static library libhdf5.a). This creates a shared library which contains the application code and the relevant bits of the static library.
When I call the Java front end, the shared library (libhdf5_jni.so) is correctly found and accessed. However, I get an UnsatisfiedLinkError which I don't understand:
Exception in thread "main" java.lang.UnsatisfiedLinkError: <blah>/lib/libhdf5_jni.so: <blah>/lib/libhdf5_jni.so: undefined symbol: _Z4formPKcz
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1485)
... etc
I have no idea what the undefined symbol "_Z4formPKcz" represents. It's not part of the application code or the static library.
Here's some more info that might help diagnosis:
1) The problem seems to be due to the approach of having a three-step process (Java code calling bespoke shared library which includes unmodified 3rd-party code). I get an identical error (including the mysterious "_Z4formPKcz" symbol) when trying to do something similar with a different 3rd-party static library.
2) When I simply have Java code calling C++ code which I have written myself (no calls to static library methods), I have no problems, i.e. there doesn't seem to be a problem with the way I set up the JNI wrappers or the application code, or in the way I create the shared library.
3) When I simply have C++ code calling the static libraries (i.e. no Java wrapper) I have no problems, i.e. there doesn't seem to be a problem with the application code or the static libraries.
4) The static libraries were compiled from source using the same compiler that I used to compile the application code.
5) I'm using J2SDK 1.4.2 on Red Hat Linux 9, although I've tried other versions of the SDK and had the same problem.
I've done a lot of web searches on the "_Z4formPKcz" symbol and have turned up absolutely nothing (zero Google hits!).
Any help would be very much appreciated.
Thanks, Jon

Thanks chrisswhite,
I should have mentioned that I tried this too and it didn't solve the problem. You're right though, I should be compiling with -fPIC anyway.
Jon

Here's a wierd one for ya' (JNI - JVM Maladies!)

I'm at my wit's end, sorry for the abstract manner in which I'm going to describe this, I don't have time to write a novel about the intricacies of what the C code described herein does and I'm sure you won't have time to read it.
I'm using JNI to wrap some C that's about a billion lines deep and at the very core of our product (it would take ten years to replace with an army of engineers).
In the back end, we start a process that allows other processes to connect to its shared memory block (it was designed to be connected to by other C executables). I've wrapped the C client that connects to the server process in JNI. To find the hooks the connecting process uses, it (the C client) reads environment variables that list the locations of files and the address at which the shared memory starts. The connecting process also grabs a semaphore created by the server process.
Okay, that said, the problem I'm having is less complicated. My JNI wrapper works perfectly every time I invoke it from the command line. The JVM comes up, loads the shared library, the C code talks to the already running process and does the work it needs to. THIS NEVER, EVER FAILS! However, when I take the very same java code and put it in a servlet, the C code I'm calling via JNI cannot find the hooks it needs (the error I'm getting has something to do with a semop()). The JNI side is working fine, I don't have a loadLibrary or class locator problem here. For some reason however, the webserver's JVM is hiding shared resources from the native code it is calling.
My question is, what is the @#$!&%#!!! difference between the two JAVA processes calling the same code? Why doesn't a servlet running in Tomcat have access to the already running process when the command line process that does have access and Tomcat have been invoked from the same environment?
I've got some theories about the webserver process having different access permissions or it's use of threads (the command line process that always works is single threaded) and child process spawning, but I don't know enough about the inner workings of the JVM to know where I should look. How do these types of permissions propagate? If the webserver process spawns a thread, does the thread have any knowledge of the environment in which its parent process was created? What about a child process? Any insights?
I've been able to break this in the same way on Solaris and HP-UX (believe it or not, NT doesn't care, I think it might have something to do with using a mutex instead of a semaphore). By the way, I'm using root to spawn all of these processes.
If you can give me a clue as to how to fix this, YOU ARE A GOD!
Anyway, your help would be appreciated!

When I'm running it from the command line, I'm usually logged in as root. I have attempted successfully to run it as other users from the command line. I'm also starting the webserver process as root.
I'm not familiar with a way to set platform specific environment variables in Tomcat, I'm sure I could use the -D option in starting the JVM. However, I have written a native stub that uses putenv() to set all of the environment variables present at the command line when I'm able to successfully invoke my JNI wrapper. This doesn't seem to change anything.
I've thought about this being a permissions propagation issue within the webserver. Any clues as to how I can confirm it?
Thanks for your help!

Can anyone shed some light on HotSpot/JNI?

I posted this to the Hotspot forum, but this place might be better ...
Hello,
I have just wrapped a C API in JNI.
It pumps messages into a callback, which are then forward to the Java side via a env->CallIntMethod(object, method, jlong, jlong).
On the java side a single accessor object is created to access the fields in the C messages. The accessors are of course JNI. A single object is created instead of a new object per message. Code snippets follow below.
Trouble is, things are incredibly slow. A C test runs in 16 seconds, the Java version takes 6 minutes!
A test which returns from the callback right away takes C 15 seconds and Java 26 seconds - still too long for the one single JNI call.
I have timed some native calls from Java to C, and found JNI calls about 7-8x slower than calls to a java method.
Even with this knowledge, I can't account for the huge performance hit.
Is is possible that my java callback, which is called from C, and all my accessor objects which are created once and call C from Java, are not being compiled to machine code but are being interpreted? Does hotspot do its stuff on existing objects? I assumed so, but I am not sure now.
Some code snippets follow (I can't post actual code because of NDA stuff)
// Class is created once at the beginning of processing, and may see
// +50million messages up to 200million or so.
public class ABCD {
private long swigCPtr;
// I call this on each new message.
void setCPtr(long ptr) {
swigCPtr = ptr;
// Accessor - goes to JNI to grab the C data.
public int getUserData1() {
return xyzJNI.get_ABCD_UserData1(swigCPtr);
And C++ code calling Java:
int JavaListener::onMessage(const System system, const Message message) {
return env->CallIntMethod(jlistener, jonMessage, (jlong)system, (jlong)message);
So now possible ideas for solutions if I can't find out what is going on:
1. Direct memory buffers. Copy the most often used data into a buffer and then unpack it on the java side.
2. UDP. Forward the messages via a UDP/localhost connection which I believe uses direct memory to transfer - but this is a pain, most of my JNI wrapper is autogenerated with SWIG. Is networking using JNI in java or some internal magic?
Any comments are welcome, as I don't want to do anything for a bit - annoying having a working Java wrapper, but unusable in any application I have.
-Ed

Argh - once again, I find my solution right after posting this. Left out one modification to the SWIG script, now it runs in 29 seconds vs C 16 seconds, I can live with that.

JNI Com CoCreateInstance VM crash

I'm trying to use the ActiveHome SDK for use in a project. The SDK is written in vb and c++. I have set up a a main class inside of my JNI wrapper to test the logic. I also set up a main class in the Java class, the test class in c++ works well when I call:
hresult = CoCreateInstance( __uuidof(ActiveHomeScriptLib::ActiveHome), NULL, CLSCTX_INPROC_SERVER, __uuidof(ActiveHomeScriptLib::IActiveHome), (LPVOID *) &pActiveHome );however this is where java is dieing. I have tried to instead call CoCreate this way:
hresult = CLSIDFromProgID(OLESTR("ActiveHomeScriptLib.ActiveHome"), &clsid);
hresult = CoCreateInstance(clsid,NULL,CLSCTX_INPROC_SERVER,__uuidof(ActiveHomeScriptLib::IActiveHome),(LPVOID *) &pActiveHome);This doesnt crash the JVM but it cannot find the OLESTR in the dll using this method.
Any help would be greatly appreciated.

karlmarxxx wrote:
Perhaps you should have read my question, I have already created a class in c++ testing this out and it works, When I run the same code in java the JVM crashes.Sorry the scrolling to see everything in single line obscured it.
Presumably when you say crash you mean a windows system error dialog versus just an exit.
When you created the C++ did you use default settings in VC from the console and for creating the jni dll?
Presumably you are doing nothing else in terms of JNI except executing that line via a JNI method?

JNI crash sockets

I am trying to write a Java library around a piece of hardware that currently does not support Java. As the first part of the task, I need to establish a TCP/IP connection between a client and server. I wrote some test code in C that is very simple socket code that can be found on tons of example sites (yes I know Java has built in classes for this, but the connection must exist in the native side).
I wrapped everything into a simple ConnectToServer and ConnectToClient functions (everything is hardcoded, so no parameters are passed) in a .so and can establish and run the connection without a hitch in a C++ program that loads the .so. When I load the .so and try to call the functions in a Java harness, the JVM crashes with a SIGSEGV in the server side during the accept call (the client does establish the connection, so it must be crashing somewhere pretty far into the accept( ) call). I have verified this crash by building and running the debug version of hotspot in gdb.
Im running Red Hat Enterprise Linux Server release 6.1 (Santiago) and Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode linux-amd64 compressed oops).
Am I not allowed to call native library functions that have system calls in them during JNI, or am I missing something else that is not immediately obvious?

jschell wrote:
891860 wrote:
I am trying to write a Java library around a piece of hardware that currently does not support Java. As the first part of the task, I need to establish a TCP/IP connection between a client and server. I wrote some test code in C that is very simple socket code that can be found on tons of example sites (yes I know Java has built in classes for this, but the connection must exist in the native side).Only reason I can think of for that would be because you need to pass the socket to your C code.
So given that.
1. Write C code that creates the socket
2. Write an API in C that uses 1 to call the library.
3. Test 1 and 2 via C code.
After step 3 is complete you do the following.
A. Determine the business functionality that your java application needs to access via the library. This step does not involve code at all. No C. No java.
B. Write an API in C that implements the functionality determined in step A. And it will use code from 1/2 as well as needed.
C. Write code in C to test B.
After you have completed step 3 and step C then you write JNI and Java.Yes, the case is that the library that Im using for this device is in C, and requires a C socket. I did pretty much the steps that you mentioned. I wrote the basic network code. I wrapped it. Then I wrote a C program to load the .so and test it. It worked fine. When I added the JNI wrapper and Java code to launch it, that is when I had the problems.
I removed everything but the basic TCP IP code (literally the wrapper that goes into JNI is just the TCP connection code). It still crashed. I then replaced the TCP IP code with another example I found on the net. Same issue. :(
Edited by: 891860 on 17-Oct-2011 15:55

Servlets and JNI

Hi,
We have a C library which does financial computations and some of our customers have expressed the need to access our library from their servlets.
This is why we have developed a JNI wrapper which encapsulates all functionality of our library.
Now, do the specs allow using JNI in conjunction with servlets? I've studied the Java EE, JSP and servlet specs but JNI isn't mentioned anywhere...
I've also found this thread with a quite similar question but without a clear answer whether it's allowed or not.
-- Vincent

yes, if the server's security policy allows it. In a basic server environment you can do just about anything you can do in a regular java application.

How to access data structures in C dll from java thru JNI?

We have been given API's( collection of C Functions) from some vendor.
SDK from vendor consist of:
Libpga.DLL, Libpga.h,Libpga.lib, Along with that sample program Receiver.h (i don't know its written in C or C++), I guess .C stnads for C files?
Considering that I don't know C or C++ (Except that I can understand what that program is doing) & i have experience in VB6 and Java, In order to build interface based on this API, I have two option left, Use these dll either from VB or Java.
As far as I know, calling this DLL in VB requires all the data structures & methods to be declared in VB, I guess which is not the case with Java (? I'm not sure)
I experiemnted calling these function from Java through JNI, and I successfully did by writting wrapper dll. My question is whether I have to declare all the constants & data structures defined in libpga.h file in java, in order to use them in my java program??
Any suggesstion would be greatly appreciated,
Vini

1. There are generators around that claim to generate suitable wrappers, given some dll input. I suggest you search google. Try JACE, jni, wrapper, generator, .... Also, serach back through this forum, where there have been suggestions made.
2. In general, you will need to supply wrappers, and if you want to use data from the "C side" in java, then you will need java objects that hold the data.

Canot call Weblogic Bean from Delphi via JNI

I tried to call a bean within the weblogiv server 7 from Delphi.
I use a JNI Wrapper which allows me easily to acces normal java objects.
I can call the bean from a java application.
When i try to call the bean via jni, the following error occurs:
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****
[ Assertion violated] at weblogic.utils.Debug.assertion(Debug.java:74)
at weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:258)
at weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:233)
at weblogic.rmi.internal.ClientRuntimeDescriptor.computeInterfaces(ClientRuntimeDescriptor.java:224)
at weblogic.rmi.internal.ClientRuntimeDescriptor.intern(ClientRuntimeDescriptor.java:123)
at weblogic.jndi.WLInitialContextFactoryDelegate.<clinit>(WLInitialContextFactoryDelegate.java:165)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:145)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:671)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:218)
at javax.naming.InitialContext.<init>(InitialContext.java:194)
at ejbtest3.ejbtest3sbTestClient1.getInitialContext(ejbtest3sbTestClient1.java:104)
at ejbtest3.ejbtest3sbTestClient1.init(ejbtest3sbTestClient1.java:32)
at ejbtest3.ejbtest3sbTestClient1.testmain(ejbtest3sbTestClient1.java:277)
It seems that i canno create a context object, but i do not know why ...
So i would be glad if anyone could help me here ...
Regards Robert

I would try this with the newest service pack since it seems this assertion does
not exist in later code lines. It appears to be related to a class loader
issue. Do you know what version of the Java VM Delphi uses?
Sam
robert wrote:
I tried to call a bean within the weblogiv server 7 from Delphi.
I use a JNI Wrapper which allows me easily to acces normal java objects.
I can call the bean from a java application.
When i try to call the bean via jni, the following error occurs:
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****
[ Assertion violated] at weblogic.utils.Debug.assertion(Debug.java:74)
at weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:258)
at weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:233)
at weblogic.rmi.internal.ClientRuntimeDescriptor.computeInterfaces(ClientRuntimeDescriptor.java:224)
at weblogic.rmi.internal.ClientRuntimeDescriptor.intern(ClientRuntimeDescriptor.java:123)
at weblogic.jndi.WLInitialContextFactoryDelegate.<clinit>(WLInitialContextFactoryDelegate.java:165)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:145)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:671)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:218)
at javax.naming.InitialContext.<init>(InitialContext.java:194)
at ejbtest3.ejbtest3sbTestClient1.getInitialContext(ejbtest3sbTestClient1.java:104)
at ejbtest3.ejbtest3sbTestClient1.init(ejbtest3sbTestClient1.java:32)
at ejbtest3.ejbtest3sbTestClient1.testmain(ejbtest3sbTestClient1.java:277)
It seems that i canno create a context object, but i do not know why ...
So i would be glad if anyone could help me here ...
Regards Robert

Jca and jni

I hope some one can answer this question , as there is no much to read about JCA
my J2EE application needs to inetgerate with some C libraries, after some investigations , I found that calling native APIs direct from the EJBs might crash the EJB container when the JNI fails, as a better solution the JCA can be used as an intermediate layer, regarding the JCA-JNI communication I have 2 questions:
1- Is this setup EJB->JCA->JNI->C failsafe against the failure in the JNI->C part?
2- can the JNI wrapper be hosted on a remote server other than the application server or will I need to install the application server on the same machine as the C libraries

1) If you mean, does the app server continue running if your native code coredumps, the answer is no - This is the tradeoff you pay for speed.
2) Yes, but you're no longer going JCA->JNI. Rather, you're going JCA->X->JNI where X is some remotable protocol.
JCA is no magic layer - It's just a Java API between application servers and whatever library you intend to expose to your app server clients.
God bless
-Toby Reyelts

Very interesting and quizzical issue in JNI COding.

HI All,
i've been facing a really frustrating, interesting and mindwrenching issue in my native code. Here is a background.
1. I was given a thirdparty ACtiveX OCX file that needed to be called through JAva.
2. I wrote a C++ JNI wrapper to call the methods of the activex object.
3. I first initialize the object, set the relevant parameters (sent from java) and then call the method I need.
4. For every record, I need to perform step 3. NOw, I am ryuning batch loads. THE code works fine for 9500 records. BUt, once the record count reaches 9885, I get a pop-up error from the activeX OCX control. I've not coded that pop-up. It comes out of the blue.
I initially thought that it could be a memory issue, but even after doubling my VM Memory allocation, I get the error. Its not a data issue, because the reocrd that causes the issue, if I run the code just for that single record, it works fine.
Below is the implemetnation of the C++ code. LEt me know if I'm doign somethign wrong or if someone has seen something like this happen before. WHAt is baffling is that it works smoothly for less records. When the pop up appears, no exception is caught on the native side also.!!!
Does java set aside some memory specfic for native libs and that is exhausted after 9885?
I'm running on windows, so is it possible to trace the internal malloc and release within the dLL?
ANy thoughts and ideas will help. I've been struggling for about three days now. ALso, do you know of a good C++ forum that i could post this question?
#include "stdafx.h"
#include "jni.h"
#import "thirdparty.ocx" raw_native_types
JNIEXPORT jstring JNICALL Java_org_nik_integration_test_Exporter_saveAsImage
(JNIEnv * env, jobject obj, jint height, jint width , jstring fileName, jstring encryptionKey, jshort encryptionAlgorithm, jstring encryptedImage, jshort imageType)
     const char* fName = NULL;
     const char* encryptionKeyc = NULL;
     const char* encImgc = NULL;
     ThirdPartyLib::_DTPPtr tpptr = 0;
     HRESULT hres = 0;
     try
          hres = ::CoCreateInstance(__uuidof(ThirdPartyLib::TP),NULL,CLSCTX_ALL, __uuidof(ThirdPartyLib::_DTP), (void**)&tpptr);
          //Retrieve values sent from Java
          fName = env->GetStringUTFChars(fileName,0);
          encryptionKeyc = env->GetStringUTFChars(encryptionKey,0);
          encImgc = env->GetStringUTFChars(encryptedImage,0);
                     tpptr->Key = _com_util::ConvertStringToBSTR(encryptionKeyc);
          tpptr->Algorithm = encryptionAlgorithm;
          tpptr->Img = _com_util::ConvertStringToBSTR(encImgc);
          tpptr->SaveUnencrypted(width, height,_com_util::ConvertStringToBSTR(fName) , 1);
     catch(_com_error &e)
          _bstr_t bstrSource(e.Source());
         _bstr_t bstrDescription(e.Description());
         printf( "Exception thrown for classes generated by #import" );
         printf( "\tCode = %08lx\n",      e.Error());
         printf( "\tCode meaning = %s\n", e.ErrorMessage());
         printf( "\tSource = %s\n",       (LPCTSTR) bstrSource);
         printf( "\tDescription = %s\n", (LPCTSTR) bstrDescription);
         // Errors Collection may not always be populated.
         if( FAILED( hres ) )
            printf( "*** HRESULT ***" );
          return NULL;
     __finally
          tpptr->Release();
          tpptr = NULL;
          //Release memory - java specific
          env->ReleaseStringUTFChars(encryptionKey, encryptionKeyc);
          env->ReleaseStringUTFChars(ink, inkc);
          env->ReleaseStringUTFChars(fileName, fName);
     }

Well you have now demonstrated conclusively that it has nothing to do with JNI.
It is either a bug with that component and/or you are using it incorrectly. Solutions to either of those would come from the source of that component, which would be somewhere besides here.
If it was a bug then you might find a way around it by doing one of the following
1. Try variations of use (options, parameters, whatever.)
2. Determine if you can solve your problem by only processing 5000 entries at a time (where 5000 chosen just to be significantly lower than the limit you have already found.) If that works then you can solve the problem by using a restartable executable that wraps the component.

Stack Overflow Error for JNI program with Jdk1.3

I wrote a JNI wrapper for a third party sofware (written in C) to use some exported functions provided. My program runs fine when using Sun JDK1.2.2, but I got the following error when using Jdk1.3 to run the program (It's a runtime error, only the version of runtime virtual machine matters.)
# An EXCEPTION_STACK_OVERFLOW exception has been detected in native code outside
the VM.
# Program counter=0x9073337
A stack overflow was encountered at address 0x09073337.
I tried IBM jdk 1.2.2, it gave me a similar error complaining about the stack overflow error.
The vendor of the third party software denies any wrong doing in their code and I don't have their source code. A test client (simulate the Java client) I wrote in C works perfectly fine and as I mentioned earlier the same java progarm runs OK with jdk 1.2.2, without any change to my system stack size. Does any body know what this is about and the solution for this?
Thanks!
My email: [email protected]

I had the same exception occur in my JNI code and I have some advice on things to look for.
Symptoms: The C++ code runs fine when called in an native executable but when it is wrapped by a JNI call inside a DLL you get the following exception:
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_STACK_OVERFLOW occurred at PC=0x100d72e5
Function name=_chkstk
The address will be different of course.
In my tests I isolated the problem to an allocation of a char array like so at the top of one of my wrapped C++ methods:
char buf[650000];
As you see this code is requesting 650000 bytes of stack memory. When run in a native executable there was no problem but when I ran it wrapped in the JNI call it blew up.
Conclusion: There is a much smaller stack space when using JNI OR the added overhead of my JNI wrapper exhausted the available stack space OR this is a stack space issue related to DLLs.
Hope this helps. Anyone with insight on this please put in your 2 cents.

JNI + existing LIBS [Win32]

- C++
- 2 existing *.lib files plus a bunch of *.h files
- no access to the source code
- very advanced libraries with custom classes/types
Q: How to create a Java wrapper for those 2 libraries?
I know that normally I would include 'jni.h' and add special keywords to the code, but:
1. I have no access to the source
2. I know it's very complex and I would drown trying to figure it out
I greatly applreciate any help,
--Snake

1) Check if SWIG ( http://www.swig.org ) can help you.
2) If you can't use SWIG, try writing an "impedance matcher".
Outline:
C++ DLL -> require complex parameters for input / output
Encapsulate heavily the methods, such that you can use less complex parameters (like XML strings) to the C++ methods. They could be callable from a plain old C program.
If you can call the methods from a plain old C program, you probably can write the JNI wrapper as well.

EXCEPTION_ACCESS_VIOLATION Jni Wrapper

Similar Messages

Maybe you are looking for