Long in JNI
hey as we have
jstring for string
jint for int
what if i have to use long
what is its equivalent
like jlong or something????????
Thanx
Yes.
And it will probably be quite a bit easier to program in JNI if you find some reference materials that document it (like a book.) Then you don't have to wait hours for an answer.
Similar Messages
-
I have a problem with JNI performance. The following simple array manipulation takes twice longer using JNI than pure Java. The dll is compiled under VC++ 4.0. Am I doing something wrong or JNI simply puts out too much overhead when calling C dll?
JNIEXPORT void JNICALL
Java_VisualEffect_zoomR(JNIEnv *env, jobject obj, jint len,jdoubleArray arr, jintArray arr1, jintArray arr2)
jint *carr1, *carr2;
jdouble *rnd;
jint i;
carr1=(*env)->GetIntArrayElements(env, arr1, NULL);
carr2=(*env)->GetIntArrayElements(env, arr2, NULL);
rnd=(*env)->GetDoubleArrayElements(env, arr, NULL);
if ( carr1==NULL|| carr2==NULL )
return 0;
if ( rnd==NULL )
return 0;
for(i=0; i<len; i++)
carr1= carr2[i]*rnd[i];
(*env)->ReleaseIntArrayElements(env, arr1, carr1,0);
(*env)->ReleaseIntArrayElements(env, arr2, carr2,0);
(*env)->ReleaseDoubleArrayElements(env, arr, rnd,0);
Appreciate any suggestions.
JayIt may also simply be that Java is actually faster than C in this trivial case or there is no difference and so the overhead matters. How big are these arrays?
-
Is it possible to call c# dll using JNI
Using JNI we can invoke native code written in c or c++.
Steps:
1) All we have to do is write a class and have a method of type native.
2) Invoke javah with -jni option to create a .h file.
3) Include this header file and implement the method in c or c++ code.
Now my question is:
Is it possible to call I want to know whether we can implement the native method in c# instead of c or c++.
ThanksNo you can't, but you can have the JNI C/C++ code call C# code. How to do that is no longer a JNI question but a C# question.
-
There are a number of bugs in the database that have the following attributes:
-JNI
-Solaris
-Signal 11 exceptions.
-Long running applications.
I am experiencing something similar. I was using C threads for some call back functionality (and of course registering it them with JNI.) I was hoping that starting the threads with java would help but it didn't.
I have several questions:
-Has anyone found anything that allows them to work around this? Doesn't matter what you think it was - like a different switch on an application server. I am just curious if anyone thinks they solved it in any way.
-Does anyone have an idea what might cause it? Even an just an idle thought?
-Does anyone have a long running application, that uses JNI on Solaris and they don't experience this (obviously the JVM itself does this, but I am still curious?)
-And slightly different that the above, does anyone have a long running JNI Solaris application using C threads that doesn't have this problem?jschell, are you still experiencing this?
You may have seen some of my posts before... I have seen many of yours. But I hadn't seen this one until now, by chance.
I am running on Solaris 8 with Java 1.3.1_03 and have a multithreaded C/C++ program that invokes the JVM and makes calls into Java via JNI. Actually, I have a few programs like this, but a particular one is set up to run as a daemon and eventually (after a couple of hours) runs into a segmentation fault (signal 11). The stack in the core file when the program fails shows that a thread started in the native code attempted "AttachCurrentThread()" and then a segfault happens way down in the JVM somewhere. However, I had an issue like this previously and I tracked it down (unexpectedly) to a memory leak in a totally unrelated portion of the native code. So I am trying to find other memory leaks in the code using tools like Rational Purify but it is tricky to get Purify and the JVM to play nicely together.
Additional info: I have all latest patches applied, not using signal handlers, and am using the "alternate" thread library in /usr/lib/lwp.
- I have another similar program on Solaris that does not seem to have this problem.
- The same program that's crashing on Solaris seems to run OK on both Windows and HP-UX.
Given the above, I am pursuing the avenue of a memory corruption in the native code as that has turned out to be the cause of numerous other problems in the past, but I am having a very hard time with this one. jschell (or anyone else), please let me know about your status and what you think.
Thanks -
Chris -
MacOSX / jni / jvm fmk 1.4.2 / passive long to a native static mtd get 0 !
I am on MacOSX 10.3.8 working with the java framework 1.4.2.
I have a problem with the JNI by passing long to a static native method (a class method). It is ok with a non static native method.
The method is in a OnX.Test class with a signature :
public static native void nativeTestStatic(long jarg1);
which is declared in C++ :
extern "C" {
JNIEXPORT void JNICALL Java_OnX_Test_nativeTestStatic(JNIEnv* aEnv,jclass jcls,jlong jarg1) {
printf("debug : %d\n",jarg1);
The printf shows always 0 !!!!
I have seen that in a big application in which some C++ code is wrapped for java by using SWIG. And C++ pointers being mapped to long, I let you imagine the disaster...
Is it a "well known problem" ????
RegardsHello
Sure, I have verified that. I have done various System.print
before the calls and within the JNI functions.
Moreover, I have now a simple test environment (then a Test.java
and a TestJNI.c) in which I pass numbers explicitly.
I have tried to pass directly like nativeFunc(123456) or doing :
long i = 123456;
nativeFunc(l);
I tried to pass big long numbers to be sure that I am not in some
tricky byteswapping situation. (sizeof(jlong) says 8 bytes for me).
What is interesting is that it is related to static methods (then class methods).
I do not see that on object methods ; here the longs are passed correctly.
Cheers -
JNI Calls to Native Methods No Longer Work: Possible Versioning Issue ?
Hello, all. Just a quick question... is it possible that invoking a method in a JNI-compliant DLL from Java 6 will fail if the DLL's source was compiled against the JNI header files from Java 4 or 5 ? I have a DLL with methods that used to be called successfully (and now fail outright and don't even seem to be getting inside the native method), but it seems that the only thing that could have changed in the environment is the installed JRE. Even stranger, I don't get the hs_err* files anymore to indicate that the JVM crashed. Does anyone know why this might happen ? Thanks !
Cthulhu76 wrote:
Hello, all. Just a quick question... is it possible that invoking a method in a JNI-compliant DLL from Java 6 will fail if the DLL's source was compiled against the JNI header files from Java 4 or 5 ? Solely? No.
You could of course be doing something in the JNI code in terms of working with Java which no longer works. Just as it is at least possible that java code from one version might not work with another.
Correct error checking in the JNI code would at least correctly identify this problem however.
I have a DLL with methods that used to be called successfully (and now fail outright and don't even seem to be getting inside the native method), but it seems that the only thing that could have changed in the environment is the installed JRE.The only thing that you assume changed was the JRE.
You seem unsure whether the JNI is being called at all, so verifying that first would be a good idea. -
Set Java Object with Java Long Object from JNI
Hi,
i am getting crazy with the jni...
in Java i have the follwoing:
public class blabla{
Object myObject;
i chose Object cause the return value from native is not known
in case for a long value i handle it like this :
//get the Long class
jclass LongCls = env->FindClass("Ljava/lang/Long;");
jmethodID jmid = env->GetMethodID(LongCls, "<init>","(J)V");
//create an Long Object with the long return value
jobject LongObj = env->NewObject(LongCls,jmid,longreturnvalue);
//set Long Objekt - doesnt work!(jclazz is the class of the return Object of the blabla class)
jfid = env->GetFieldID(jclazz, "myObject", "Ljava/lang/Object;");
env->SetObjectField( returnobjectofblabla,jfid,LongObj );
the long value is set fine in the Long Object but i cant set the Long Object with the SetObjectField method into the Object myObject.
Java is shown that the myObject contains a Long Object but the long value of the Long Object is totally wrong and doesnt equal to the long value which has been set.But setting the value works fine- any ideas or solutions?
Thank you!charliess wrote:
sometimes i really wonder about the answers in this forum - until now i got not one answer that helps me, even i tried to write down the problem very detailed...
Sometimes I wonder about people who jump onto a site and immediately assume that
1. They are the most important person in the world
2. That they deserved the absolute undivided attention of absolute everyone.
3. That everyone should be absolutely polite to them and provide them with perfect answers.
4. Feel free to denigrate and posit their own opinion on everything while ignoring anything else that anyone else says.
5. Expect that everyone else should understand their poorly worded questions.
Myself I find such individuals extremely amusing. Although they seldom stick around long here. At least not under their original alias.
plaz tel me how to realise your error checking?example plz
You start by having at least a basic understanding of C/C++ and java.
Then you read the JNI documents, all of them, for each method that you are using.
Then you write code such that it actually reflects the documents. For example you check return types. And probably deal with the possibility that JNI methods might throw exceptions.
as far as i know the jni methods like getfieldids and so on throw exceptions other like stObject dont do that the just return nothing
i can see all exceptions in my Java console thats not the Problem, setting the Long Object does not throwing a exception btw->
Myself I wouldn't expect that a JNI exception would show in the java console. Could I suppose though.
However nothing so far would suggest that an exception is being thrown. That however doesn't alter the fact that you must still write the code such that it could happen.
is it possible in general to set an java Long Object created in C(native) into a Object type (Object) overgiven as parameter in my JNI function with the setObject method?
Is it possible that you could actually follow my previous request and create some code that actually runs instead of cut and pasting whatever you feel like?
plz answer also with code and examples i did the same for you...No you didn't. You posted something which would not compile and quite possibly doesn't represent your actual code at all.
And please note that we do not get paid to do this. If you want to pay someone to solve your problem then there are sites for that.
Paying someone allows you to make all sorts of demands. The more you pay the more people will put up with.
If you don't want to pay and do in fact want free answers then it will probably be in your interest to
1. Be polite
2. Answer the questions that have been asked of you. -
JNI MMX and Java long arithmetic
I am having trouble with a JNI call to a C program which contains assembler which uses an MMX operation as follows:
static inline int diffPixels(int rgb1, int rgb2) {
register int temp;
__asm__ __volatile__ (
"movd %1, %%mm1\n\t"
"movd %2, %%mm2\n\t"
"psadbw %%mm1, %%mm2\n\t"
"movd %%mm2, %0\n\t"
: "=r" (temp)
: "r" (rgb1), "r" (rgb2)
: "mm1", "mm2", "cc"
return temp;
After the JNI call returns, the first Java long arithmetic fails. I believe the failure is that when a method on a Java object returns a long the result is 0x8000000000000000 rather than the correct value.
To use pure Java means my response to a user action is 9 seconds rather than 3 seconds with the JNI call which is why I want to persist with it. At present I am doing an arbitrary long multiply after the JNI call to "fix" long arithmetic but I am afraid this won't work if there is a context switch to another java thread in the middle of the JNI call.
The test environment is a 3 Gigahertz Pentium 4 running Linux kernel 2.6.9 and Java version 1.4.2_06-b03.
Can anyone explain this behaviour ? It took me days to isolate the problem.Hi,
Is it absolutely necessary to declare temp as register ?
How about adding a lock directive at the beginning of your asm ?
--Marc (http://jnative.sf.net) -
Problem with JNI and Tomcat in windows
Hello guys...
I have the following problem.
I used Tomcat 4 and I have following ApiEncriptacion class, in package com.servipag.sts;
package com.servipag.sts;
class ApiEncriptacion
public native String encripta(String texto, String ubicacionLlavePublica, String semilla);
static
System.loadLibrary("apisdark");
public native String desencripta(String texto, String ubicacionLlavePrivada);
static
System.loadLibrary("apisdark");
the LD_LIBRARY_PATH is set in following dir c:\tomcat\bice
the dll this in the following path = c:\tomcat\bice\apisdark.dll
I run Tomcat at the following way..
C:\jdk1.4\bin\java.exe -jar -Djava.library.path="c:\tomcat\bice" -Duser.dir="C:\Tomcat" "C:\Tomcat\bin\bootstrap.jar" start
but, still appear the error:
java.lang.UnsatisfiedLinkError: encripta
at com.servipag.sts.ApiEncriptacion.encripta(Native Method)
at com.servipag.sts.ServiciosServiPagImpl.rescatarFirma(ServiciosServiPagImpl.java:2143)
at com.servipag.sts.ServiciosServiPagImpl.pagarCuenta(ServiciosServiPagImpl.java:310)
at org.apache.jsp.SBCO_0005flogin_0005fbice_0005f4$jsp._jspService(SBCO_0005flogin_0005fbice_0005f4$jsp.java:265)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:201)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1012)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1107)
at java.lang.Thread.run(Thread.java:536)
please help me
Luis Navarro.
ChileApiEncripatcion.h
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class ApiEncriptacion */
#ifndef IncludedApiEncriptacion
#define IncludedApiEncriptacion
#ifdef __cplusplus
extern "C" {
#endif
* Class: ApiEncriptacion
* Method: encripta
* Signature: (Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
JNIEXPORT jstring JNICALL Java_ApiEncriptacion_encripta
(JNIEnv *, jobject, jstring, jstring, jstring);
* Class: ApiEncriptacion
* Method: desencripta
* Signature: (Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
JNIEXPORT jstring JNICALL Java_ApiEncriptacion_desencripta
(JNIEnv *, jobject, jstring, jstring);
#ifdef __cplusplus
#endif
#endif
ApiEncriptacion.c
#include "jni.h"
#include <stdio.h>
#include "files.h"
#include "hex.h"
#include "rsa.h"
#include "randpool.h"
USING_NAMESPACE(CryptoPP)
USING_NAMESPACE(std)
void GenerateRSAKey(unsigned int keyLength, const char privFilename, const char pubFilename, const char *seed);
char RSAEncryptString(const char pubFilename, const char seed, const char message);
char RSADecryptString(const char privFilename, const char *ciphertext);
JNIEXPORT jstring JNICALL
Java_ApiEncriptacion_encripta(JNIEnv *env, jobject obj, jstring texto, jstring ubicacionLlavePublica, jstring semilla)
try
char *ciphertext = RSAEncryptString(ubicacionLlavePublica, semilla, texto);
delete [] ciphertext;
return(ciphertext);
catch(CryptoPP::Exception &e)
return ("");
catch(std::exception &e)
return ("");
catch(...)
return ("");
JNIEXPORT jstring JNICALL
Java_ApiEncriptacion_desencripta(JNIEnv *env, jobject obj, jstring texto, jstring ubicacionLlavePrivada)
try
char *decrypted = RSADecryptString(ubicacionLlavePrivada, texto);
return(decrypted);
catch(CryptoPP::Exception &e)
return ("");
catch(std::exception &e)
return ("");
catch(...)
return ("");
int main()
return(0);
void GenerateRSAKey(unsigned int keyLength, const char privFilename, const char pubFilename, const char *seed)
RandomPool randPool;
randPool.Put((byte *)seed, strlen(seed));
RSAES_OAEP_SHA_Decryptor priv(randPool, keyLength);
HexEncoder privFile(new FileSink(privFilename));
priv.DEREncode(privFile);
privFile.MessageEnd();
RSAES_OAEP_SHA_Encryptor pub(priv);
HexEncoder pubFile(new FileSink(pubFilename));
pub.DEREncode(pubFile);
pubFile.MessageEnd();
char RSAEncryptString(const char pubFilename, const char seed, const char message)
FileSource pubFile(pubFilename, true, new HexDecoder);
RSAES_OAEP_SHA_Encryptor pub(pubFile);
if (strlen(message) > pub.MaxPlainTextLength())
cerr << "message too long for this key\n";
abort();
RandomPool randPool;
randPool.Put((byte *)seed, strlen(seed));
char outstr = new char[2pub.CipherTextLength()+1];
pub.Encrypt(randPool, (byte *)message, strlen(message), (byte *)outstr);
HexEncoder hexEncoder;
hexEncoder.Put((byte *)outstr, pub.CipherTextLength());
hexEncoder.MessageEnd();
hexEncoder.Get((byte *)outstr, 2*pub.CipherTextLength());
outstr[2*pub.CipherTextLength()] = 0;
return outstr;
char RSADecryptString(const char privFilename, const char *ciphertext)
FileSource privFile(privFilename, true, new HexDecoder);
RSAES_OAEP_SHA_Decryptor priv(privFile);
HexDecoder hexDecoder;
hexDecoder.Put((byte *)ciphertext, strlen(ciphertext));
hexDecoder.MessageEnd();
SecByteBlock buf(priv.CipherTextLength());
hexDecoder.Get(buf, priv.CipherTextLength());
char *outstr = new char[priv.MaxPlainTextLength()+1];
unsigned messageLength = priv.Decrypt(buf, (byte *)outstr);
outstr[messageLength] = 0;
return outstr; -
JNI Invocation: open file in Java, write file in CPP
Hello,
Warning: I am a dunce, bad CPP code ahead!
Using JNI invocation, I am trying to read a binary file in Java and write it in CPP.
Everything compiles and runs without error, but the input and output jpg files are of course different.
TIA to any help,
kirst
(begin ByteMe.java)
import java.io.*;
public class ByteMe
// Returns the contents of the file in a byte array.
public byte[] getBytesFromFile(String strInfo) throws IOException
System.out.println("Testing:" + strInfo);
File file = new File("1.jpg");
InputStream is = new FileInputStream(file);
// Get the size of the file
long length = file.length();
// Create the byte array to hold the data
byte[] bytes = new byte[(int)length];
// Read in the bytes
int offset = 0;
int numRead = 0;
while (offset < bytes.length
&& (numRead=is.read(bytes, offset, bytes.length-offset)) >= 0) {
offset += numRead;
// Ensure all the bytes have been read in
if (offset < bytes.length)
throw new IOException("Could not completely read file "+file.getName());
// Close the input stream and return bytes
is.close();
return bytes;
public ByteMe()
//System.out.println("in constructor");
}(end ByteMe.java)
(begin ByteMe.cpp)
#include <stdlib.h>
#include <string.h>
#include <jni.h>
#include <windows.h>
// for file operations:
#include <fstream>
int main( int argc, char *argv[] )
JNIEnv *env;
JavaVM *jvm;
JavaVMInitArgs vm_args;
JavaVMOption options[5];
jint res;
jclass cls;
jmethodID mid;
jstring jstr;
jobject obj_print;
options[0].optionString = "-Xms4M";
options[1].optionString = "-Xmx64M";
options[2].optionString = "-Xss512K";
options[3].optionString = "-Xoss400K";
options[4].optionString = "-Djava.class.path=.";
vm_args.version = JNI_VERSION_1_4;
vm_args.options = options;
vm_args.nOptions = 5;
vm_args.ignoreUnrecognized = JNI_FALSE;
// Create the Java VM
res = JNI_CreateJavaVM(&jvm,(void**)&env,&vm_args);
if (res < 0)
printf("Can't create Java VM");
goto destroy;
cls = env->FindClass("ByteMe");
if (cls == 0)
printf("Can't find ByteMe class");
goto destroy;
jmethodID id_construct = env->GetMethodID(cls,"<init>","()V");
jstr = env->NewStringUTF(" from C++\n");
obj_print = env->NewObject(cls,id_construct);
// signature obtained using javap -s -p ByteMe
mid = env->GetMethodID(cls, "getBytesFromFile", "(Ljava/lang/String;)[B");
if (mid == 0)
printf("Can't find ByteMe.getBytesFromFile\n");
goto destroy;
else
jbyteArray jbuf = (jbyteArray) env->CallObjectMethod(obj_print,mid,jstr);
jlong size = jsize(jbuf);
printf("size is: %d\n", size); // size shown in output is
std::ofstream out("data.jpg", std::ios::binary);
out.write ((const char *)jbuf, 100000);
destroy:
if (env->ExceptionOccurred())
env->ExceptionDescribe();
jvm->DestroyJavaVM();
}(end ByteMe.cpp)Hello,
Me again. Well, not such a dunce after all. Here is code that works correctly, and compiles with no errors and no warnings.
Will much appreciate help with clean-up code.
TIA,
kirst
(begin ByteMe.java)
import java.io.*;
public class ByteMe
public long getFilezize(String strInfo) throws IOException
// demonstrates String parameter passed from CPP to Java:
System.out.println("(getFilesize) Hello world" + strInfo);
File file = new File("1.bmp");
InputStream is = new FileInputStream(file);
// Get the size of the file
long length = file.length();
is.close();
return length;
// Returns the contents of the file in a byte array.
public byte[] getBytesFromFile(String strInfo) throws IOException
System.out.println("(getBytesFromFile) Hello world" + strInfo);
File file = new File("1.bmp");
InputStream is = new FileInputStream(file);
// Get the size of the file
long length = file.length();
System.out.println("length is: " + String.valueOf(length));
// Create the byte array to hold the data
byte[] bytes = new byte[(int)length];
// Read in the bytes
int offset = 0;
int numRead = 0;
while (offset < bytes.length && (numRead=is.read(bytes, offset, bytes.length-offset)) >= 0)
offset += numRead;
// Ensure all the bytes have been read in
if (offset < bytes.length)
throw new IOException("Could not completely read file "+ file.getName());
// Close the input stream and return bytes
is.close();
return bytes;
public ByteMe()
//System.out.println("in constructor");
}(end ByteMe.java)
(begin ByteMe.cpp)
Signature obtained with command:
"C:\Program Files\Java\jdk1.5.0_15\bin\javap.exe" -s -p ByteMe
Compiled from "ByteMe.java"
public class ByteMe extends java.lang.Object{
public long getFilezize(java.lang.String) throws java.io.IOException;
Signature: (Ljava/lang/String;)J
public byte[] getBytesFromFile(java.lang.String) throws java.io.IOException;
Signature: (Ljava/lang/String;)[B
public ByteMe();
Signature: ()V
Compiled VC++ 2005 Express, run on Vista
#include <stdlib.h>
#include <string.h>
#include <jni.h>
// file operations
#include <fstream>
int main( int argc, char *argv[] )
JNIEnv *env;
JavaVM *jvm;
JavaVMInitArgs vm_args;
JavaVMOption options[5];
jint res;
jclass cls;
jmethodID mid;
jmethodID sizeid;
jstring jstr;
jobject obj_print;
jlong filesize;
options[0].optionString = "-Xms4M";
options[1].optionString = "-Xmx64M";
options[2].optionString = "-Xss512K";
options[3].optionString = "-Xoss400K";
options[4].optionString = "-Djava.class.path=.";
vm_args.version = JNI_VERSION_1_4;
vm_args.options = options;
vm_args.nOptions = 5;
vm_args.ignoreUnrecognized = JNI_FALSE;
// Create the Java VM
res = JNI_CreateJavaVM(&jvm,(void**)&env,&vm_args);
if (res < 0)
printf("Can't create Java VM");
goto destroy;
cls = env->FindClass("ByteMe");
if (cls == 0)
printf("Can't find ByteMe class");
goto destroy;
jmethodID id_construct = env->GetMethodID(cls,"<init>","()V");
printf("%s\n",id_construct);
jstr = env->NewStringUTF(" from C++!\n");
if (jstr == 0)
// Normally not useful
printf("Out of memory (could not instantiate new string jstr)\n");
goto destroy;
obj_print = env->NewObject(cls,id_construct);
//BEGIN BLOCK to get file size
sizeid = env->GetMethodID(cls, "getFilezize", "(Ljava/lang/String;)J");
if (sizeid == 0)
printf("Can't find ByteMe.getFilezize\n");
goto destroy;
else
printf("got here\n");
filesize =(jlong) env->CallObjectMethod(obj_print,sizeid,jstr);
printf("got filesize\n");
// END BLOCK to get file size
// BEGIN BLOCK to write file
mid = env->GetMethodID(cls, "getBytesFromFile", "(Ljava/lang/String;)[B");
if (mid == 0)
printf("Can't find ByteMe.getBytesFromFile\n");
goto destroy;
else
jbyteArray ret =(jbyteArray) env->CallObjectMethod(obj_print,mid,jstr);
// Access the bytes:
jbyte *retdata = env->GetByteArrayElements(ret, NULL);
// write the file
std::ofstream out("data.bmp", std::ios::binary);
//out.write ((const char *)retdata, 921654);
out.write ((const char *)retdata, (long)filesize);
// END BLOCK to write file
destroy:
if (env->ExceptionOccurred())
env->ExceptionDescribe();
jvm->DestroyJavaVM();
}(end ByteMe.cpp) -
JNI - How to use the error reporting mechanism?
I've developed a C++ DLL which is loaded from a commercial Win32 application (not written by me) as a plug-in for external calculations. On its initialization the C++ DLL launches the Java VM via the JNI invocation interface. When the DLL functions are called by the application, they forward the calls to Java objects inside the Java VM, again via JNI invocation interface.
This works well, but I have encountered a weird error.
From Java I open a JFrame containing a JTextArea as small console for debug output messages. If I turn output to this debug console off (my printToConsole routine checks whether a boolean flag is set), the string concatenation operator may lead to a crash of the Java VM.
For example, if in one of the Java functions called from the
DLL via JNI invocation interface the following is the first statement,
it leads to a crash of the Java VM and the application that loaded the C++ proxy DLL.
String test=""+Math.random(); // String test not used later
Interestingly, if I comment this statement out, the Java code works fine WITHOUT any crash. I've already thought about potential races and synchronization issues in my code, but I don't see where this is the case. And the string concatenation error fails as well, if I insert sleep() statements in front of it and at other places in the code. However, if I turn on log messages printed to my JFrame debug console (containing a JTextArea), the String concatenation works without problems.
So maybe the JNI interface has a bug and affects the Java VM; I don't see where my JNI code is wrong.
One problem is that I do not get any stdout output, as the C++ proxy DLL is loaded by the Windows application, even if I start the Windows application from the DOS command line (under Windows).
Does anyone know how to use the error reporting mechanism?
http://java.sun.com/j2se/1.4.2/docs/guide/vm/error-handling.html
Is it possible that the JVM, when it crashes, writes debug information about the crash into a file instead of stdout/stderr?
My C++ proxy DLL was compiled in debug mode, but the commercial application (which loaded the DLL) is very likely not.
I do not know hot to find the reason why the String concatenation fails inside the Java function called from the C++ DLL via JNI.Yes, I've initially thought about errors in the C++ code too. But the C++ code is actually very simple and short. It doesn't allocate anything on the C++ side. It allocates a couple of ByteBuffers inside the Java VM however via JNI invocation interface calls of env->NewDirectByteBuffer(). The native memory regions accessed via the ByteBuffers are allocated not by my own C++ code, but by the program that calls my DLL (the program is Metastock).
The interesting thing is that everything works fine if output to my debug console is enabled, which means that in the Java print routine getConsoleLoggingState() returns true and text is appended to the jTextArea.
static synchronized void print(String str)
{ MetaStockMonitor mMon=getInstance();
if ( mMon.getFileLoggingState() && mMon.logFileWriter!=null) {
mMon.logFileWriter.print(str);
mMon.logFileWriter.flush();
if ( mMon.getConsoleLoggingState() ) {
mMon.jTextArea1.append(str);
Only if output to the JTextArea is turned off (ie. getConsoleLoggingState()==false), the crash happens when the FIRST statement in the Java routine called via JNI invocation interface is a (useless) String concatenation operation, as described above.
String test=""+Math.random(); // String test not used later
Moreover, the crash happens BEFORE the allocated ByteBuffer objects are accessed in the Java code. But again, if console output is turned on, it works stable. If console output is turned off, it works when the (useless) String concatenation operation is removed in the Java routine called from C++.
I've already thought about potential races (regarding multiple threads), but this can be ruled out in my case. It almost appears as if the JVM can have problems when called by the invocation interface (I tested it with Java 1.4.2 b28).
All the calls between C++ and Java go ALWAYS in the direction from C++ code to Java. Unfortunately, there is no special JRE version with extensive logging capabilities to facilitate debugging. And the problem is not easily reproducible either.
JNIEnv* JNI_GetEnv()
JNIEnv *env;
cached_jvm->AttachCurrentThread((void**)&env,NULL);
fprintf(logfile,"env=%i\n",env);
fflush(logfile);
return env;
// function called by Metastock's MSX plug-in interface
BOOL __stdcall createIndEngine (const MSXDataRec *a_psDataRec,
const MSXDataInfoRecArgsArray *a_psDataInfoArgs,
const MSXNumericArgsArray *a_psNumericArgs,
const MSXStringArgsArray *a_psStringArgs,
const MSXCustomArgsArray *a_psCustomArgs,
MSXResultRec *a_psResultRec)
a_psResultRec->psResultArray->iFirstValid=0;
a_psResultRec->psResultArray->iLastValid=-1;
jthrowable ex;
jmethodID mid;
JNIEnv* env=JNI_GetEnv();
jobject chart=getChart(env, a_psDataRec);
if ( chart==NULL) {
return MSX_ERROR;
jobject getChart (JNIEnv* env, const MSXDataRec *a_psDataRec)
jthrowable ex;
jmethodID mid;
int closeFirstValid, closeLastValid;
closeFirstValid=a_psDataRec->sClose.iFirstValid;
closeLastValid=a_psDataRec->sClose.iLastValid;
long firstDate, firstTime;
if (closeFirstValid>=1 && closeFirstValid<=closeLastValid) {
firstDate = a_psDataRec->psDate[closeFirstValid].lDate;
firstTime = a_psDataRec->psDate[closeFirstValid].lTime;
} else {
firstDate=0;
firstTime=0;
jclass chartFactoryClass = env->FindClass("wschwendt/metastock/msx/ChartFactory");
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Cannot find class ChartFactory\n");
printSBufViaJava(sbuf);
return NULL;
mid = env->GetStaticMethodID(chartFactoryClass, "getInstance", "()Lwschwendt/metastock/msx/ChartFactory;");
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Cannot find method ID for ChartFactory.getInstance()\n");
printSBufViaJava(sbuf);
return NULL;
jobject chartFactory=env->CallStaticObjectMethod(chartFactoryClass, mid);
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Exception while calling ChartFactory.getInstance()");
printSBufViaJava(sbuf);
return NULL;
mid = env->GetMethodID(chartFactoryClass, "getChartID", "(Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;IIIIIII)F");
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Cannot find method ID for ChartFactory.getChartID()\n");
printSBufViaJava(sbuf);
return NULL;
jobject symbolBuf=env->NewDirectByteBuffer(a_psDataRec->pszSymbol, strlen(a_psDataRec->pszSymbol) );
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Cannot allocate symbolBuf\n");
printSBufViaJava(sbuf);
return NULL;
jobject securityNameBuf=env->NewDirectByteBuffer(a_psDataRec->pszSecurityName, strlen(a_psDataRec->pszSecurityName) );
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Cannot allocate securityNameBuf\n");
printSBufViaJava(sbuf);
return NULL;
jobject securityPathBuf=env->NewDirectByteBuffer(a_psDataRec->pszSecurityPath, strlen(a_psDataRec->pszSecurityPath) );
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Cannot allocate securityPathBuf\n");
printSBufViaJava(sbuf);
return NULL;
jobject securityOnlineSourceBuf=env->NewDirectByteBuffer(a_psDataRec->pszOnlineSource, strlen(a_psDataRec->pszOnlineSource) );
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Cannot allocate onlineSourceBuf\n");
printSBufViaJava(sbuf);
return NULL;
// Java Function call leads to crash, if console output is turned off and
// the first statement in the Java routine is a (useless) string concatenation.
// Otherwise it works stable.
jfloat chartID=env->CallFloatMethod(chartFactory, mid, securityNameBuf, symbolBuf,
securityPathBuf, securityOnlineSourceBuf, (jint)(a_psDataRec->iPeriod),
(jint)(a_psDataRec->iInterval), (jint)(a_psDataRec->iStartTime),
(jint)(a_psDataRec->iEndTime), (jint)(a_psDataRec->iSymbolType),
(jint)firstDate, (jint)firstTime );
if (ex= env->ExceptionOccurred() ) {
env->ExceptionDescribe();
env->ExceptionClear();
sprintf(sbuf, "DLL: Exception while calling ChartFactory.getChartID()");
printSBufViaJava(sbuf);
return NULL; -
XI - J2ee takes long time to startup after SP19
Hi everybody,
we have patched our XI development system to SP 19; during startup of j2ee it takes a long time in registering method in com.sap.security.core.server.vsi.service.jni.VirusScanInterface....about 10 minutes!
Here follow an extract of dev_server0 tarce file:
JHVM_BuildArgumentList: main method arguments of node [server0]
[Thr 3600] Wed Jan 24 15:10:14 2007
[Thr 3600] JHVM_RegisterNatives: registering methods in com.sap.bc.proj.jstartup.JStartupFramework
[Thr 3600] JLaunchISetClusterId: set cluster id 5501650
[Thr 3600] JLaunchISetState: change state from [Initial (0)] to [Waiting for start (1)]
[Thr 3600] JLaunchISetState: change state from [Waiting for start (1)] to [Starting (2)]
[Thr 31100] Wed Jan 24 15:10:48 2007
[Thr 31100] JHVM_RegisterNatives: registering methods in com.sap.mw.rfc.driver.CpicDriver
[Thr 31100] JHVM_RegisterNatives: registering methods in com.sap.mw.jco.util.SAPConverters
[Thr 31100] JHVM_RegisterNatives: registering methods in com.sap.mw.jco.util.SAPCharToNUCByteConverter
[Thr 31100] Wed Jan 24 15:10:50 2007
[Thr 31100] JHVM_RegisterNatives: registering methods in com.sap.mw.rfc.engine.Compress
<b>[Thr 25960] Wed Jan 24 15:11:02 2007
[Thr 25960] JHVM_RegisterNatives: registering methods in com.sap.security.core.server.vsi.service.jni.VirusScanInterface</b>
[Thr 3600] Wed Jan 24 15:21:40 2007
[Thr 3600] JLaunchISetState: change state from [Starting (2)] to [Starting applications (10)]
[Thr 23390] Wed Jan 24 15:24:40 2007
[Thr 23390] JLaunchISetState: change state from [Starting applications (10)] to [Running (3)]
Is there any way to speed up this process? or to deactivate the virusscaninterface service? What can I check to understand what happens during the registering method of VirusScanInterface?
We are using XI on AIX platform, version 5.3 ML5 with Oracle database.
Thanks in advance.
Best regards.
TizianoHello there, mabaaref.
The following Knowledge Base article provides some great information in regards to battery functionality:
iPhone and iPod touch: Charging the battery
http://support.apple.com/kb/HT1476
It's important to note that if the battery is extremely low on power, your device may display a black screen for up to two minutes before one of these images appears. Continue charging for at least 30 minutes, or until your device is fully charged.
Thanks for reaching out to Apple Support Communities.
Cheers,
Pedro. -
JVM Crash When Using JNI and COM
I'm trying to call a DLL compiled from VB6 source code that I do not have access to. The VB6 code simply retrieves data from a DB2 database using ADO and my client code grabs that data and marshals it to my Java code. I'm attempting to achieve this using JNI and COM (without a third-party bridge). It works 75% of the time, but the other 25% of the time, the JVM crashes with the usual Hotspot crash log containing an access violation exception. However, I don't know what in my C++ code (VC++ 8) could be causing this except for passing a "wild" pointer to the code lying underneath the COM object interface. If that is the case, I don't know how I am doing that.
The Java code that is calling my native method is running on Tomcat 5.5.25 and just to be safe, I am not allowing multiple threads to concurrently call the method in my JNI DLL (though I realize that this will kill performance). Once I can get past this problem, I'll do the COM interfacing on a worker thread in my native code so I don't screw up CoInitialize and CoUninitialize calls in the case the same thread is concurrently executing multiple calls to my native code.
I've noticed that in most cases, the JVM crashes during my call to the pClsAccount->OpenConnection method. However, my DLL isn't what is listed on the top of the call stack, which is why I suspect the passing of a wild pointer, though I'm just taking a guess at that. Does anyone have an idea as to what's going on ?
JNIEXPORT jobject JNICALL Java_CustomerInfo_nGetCustomerAccountInfo(JNIEnv *env, jobject customerInfo, jstring accountNumber, jstring iniFileName)
jboolean isCopy;
// Account info class and instance to be instantiated
jclass accountInfoCls = NULL;
jobject accountInfoObj = NULL;
// The constructor ID of the accountInfoCls
jmethodID ctorID = NULL;
// Pointer to the interface for the ClsAccount COM object
_clsAccount *pClsAccount = NULL;
HRESULT hr;
BSTR bstrIniFileName(L"");
try
const char *nativeAccountNumber = NULL;
if (accountNumber != NULL)
nativeAccountNumber = env->GetStringUTFChars(accountNumber, &isCopy);
else
jclass newExcCls;
env->ExceptionDescribe();
env->ExceptionClear();
newExcCls = env->FindClass("java/lang/IllegalArgumentException");
env->ThrowNew(newExcCls, "accountNumber passed in was null !");
return NULL;
// Initialization
variantt varConnectionSucceeded = variantt(false);
variantt varGetAccountInfoSucceeded = variantt(false);
variantt varAccountNumber = variantt(nativeAccountNumber);
bstrt bstrLastPaymentDate = bstrt();
bstrt bstrLastErrorMessage = bstrt();
bstrt bstrLastErrorNumber = bstrt();
jlong jTotalDue = NULL;
jlong jEstablishedDueDay = NULL;
jlong jLastPaymentAmount = NULL;
jstring jLastPaymentDate = NULL;
jstring jLastErrorMessage = NULL;
jstring jLastErrorNumber = NULL;
jthrowable jException = NULL;
const char *chLastPaymentDate = NULL;
const char *chLastErrorMessage = NULL;
const char *chLastErrorNumber = NULL;
long long totalDue;
long long lastPaymentAmount;
long establishedDueDateDay;
//Convert string from Java string to C string to VB string
const char *nativeIniFileName = NULL;
if (iniFileName != NULL)
nativeIniFileName = env->GetStringUTFChars(iniFileName, &isCopy);
else
jclass newExcCls;
env->ExceptionDescribe();
env->ExceptionClear();
newExcCls = env->FindClass("java/lang/IllegalArgumentException");
env->ThrowNew(newExcCls, "iniFileName passed in was null");
return NULL;
bstrIniFileName = comutil::ConvertStringToBSTR(nativeIniFileName);
CoInitialize(NULL);
// Create an instance of the COClass with the interface over it
hr = CoCreateInstance(__uuidof(clsAccount), NULL, CLSCTX_INPROC_SERVER, __uuidof(_clsAccount), (void **)&pClsAccount);
if (hr == S_OK)
varConnectionSucceeded.boolVal = pClsAccount->OpenConnection(&bstrIniFileName);
　
if (varConnectionSucceeded.boolVal == -1)
varGetAccountInfoSucceeded.boolVal = pClsAccount->GetAccountPaymentInformation(&(varAccountNumber.GetVARIANT()));
env->ReleaseStringUTFChars(accountNumber, nativeAccountNumber);
// Extract all available account information from the ClsAccount object
if (varGetAccountInfoSucceeded.boolVal == -1)
totalDue = pClsAccount->TotalDue.int64;
establishedDueDateDay = pClsAccount->EstablishedDueDateDay;
lastPaymentAmount = pClsAccount->LastPaymentAmount.int64;
bstrLastPaymentDate = pClsAccount->LastPaymentDate;
chLastPaymentDate = comutil::ConvertBSTRToString(bstrLastPaymentDate.GetBSTR());
jTotalDue = (jlong)totalDue;
jEstablishedDueDay = (jlong)establishedDueDateDay;
jLastPaymentAmount = (jlong)lastPaymentAmount;
jLastPaymentDate = env->NewStringUTF(chLastPaymentDate);
delete[] chLastPaymentDate;
pClsAccount->CloseConnection();
// Populate error fields if any errors occur
bstrLastErrorMessage = pClsAccount->LastErrMessage;
chLastErrorMessage = comutil::ConvertBSTRToString(bstrLastErrorMessage.GetBSTR());
bstrLastErrorNumber = pClsAccount->LastErrNumber;
chLastErrorNumber = comutil::ConvertBSTRToString(bstrLastErrorNumber.GetBSTR());
jLastErrorMessage = env->NewStringUTF(chLastErrorMessage);
jLastErrorNumber = env->NewStringUTF(chLastErrorNumber);
delete[] chLastErrorMessage;
delete[] chLastErrorNumber;
const char* clsName = "com/nuance/merchantsmutual/businessentities/CustomerAccountInfo";
// Find the Java class and the ID of its constructor
accountInfoCls = env->FindClass(clsName);
ctorID = env->GetMethodID(accountInfoCls, "<init>", "(JJJLjava/lang/String;Ljava/lang/String;Ljava/lang/String;)V");
jException = env->ExceptionOccurred();
if (jException != NULL)
env->ExceptionDescribe();
env->ExceptionClear();
//Release all resources associated with the ClsAccount instance
pClsAccount->Release();
//Instantiate the class with the given parameters
accountInfoObj = env->NewObject(accountInfoCls, ctorID, jTotalDue, jEstablishedDueDay, jLastPaymentAmount, jLastPaymentDate, jLastErrorMessage, jLastErrorNumber);
jException = env->ExceptionOccurred();
if (jException != NULL)
env->ExceptionDescribe();
env->ExceptionClear();
else if (hr == REGDB_E_CLASSNOTREG)
cout << "COM class not registered" << endl;
else if ( hr == CLASS_E_NOAGGREGATION)
cout << "COM class can't be aggregated" << endl;
else if (hr == E_NOINTERFACE)
cout << "No interface for COM class clsAccount" << endl;
else if (hr == E_POINTER)
cout << "*ppv pointer was NULL !" << endl;
else
cout << "Error occurred while creating COM object. HR is [" << hr << "]" << endl;
// Free the BSTR because a new one was returned with a call to comutil::ConvertStringToBSTR
SysFreeString(bstrIniFileName);
// Release the string when it's no longer needed. MUST call if string won't be used
// anymore or else a memory leak will occur
env->ReleaseStringUTFChars(iniFileName, nativeIniFileName);
CoUninitialize();
　
catch (_com_error &e)
cout << "Encountered an exception in GetCustomerAccountInfo: Error was " << e.ErrorMessage();
pClsAccount->Release();
catch (...)
pClsAccount->Release();
return accountInfoObj;
Edited by: Cthulhu76 on Jan 5, 2010 9:18 AM0x49202400 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=5340, stack(0x49bf0000,0x49c40000)]
0x48a7e800 JavaThread "Thread-1" [_thread_in_native, id=5976, stack(0x48f00000,0x48f50000)]
0x48a0dc00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3072, stack(0x48c60000,0x48cb0000)]
0x48a09000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=4988, stack(0x48c10000,0x48c60000)]
0x48a07c00 JavaThread "Attach Listener" daemon [_thread_blocked, id=3124, stack(0x48bc0000,0x48c10000)]
0x48a07000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2572, stack(0x48b70000,0x48bc0000)]
0x489f5c00 JavaThread "Finalizer" daemon [_thread_blocked, id=5752, stack(0x48b20000,0x48b70000)]
0x489f4c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=2596, stack(0x48ad0000,0x48b20000)]
0x003c6000 JavaThread "main" [_thread_in_native, id=4252, stack(0x00820000,0x00870000)]
Other Threads:
0x489f0400 VMThread [stack: 0x48a80000,0x48ad0000] [id=5624]
0x48a18800 WatcherThread [stack: 0x48cb0000,0x48d00000] [id=1192]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 36288K, used 12762K [0x02940000, 0x050a0000, 0x07800000)
eden space 32256K, 34% used [0x02940000, 0x0343af58, 0x048c0000)
from space 4032K, 37% used [0x04cb0000, 0x04e2ba28, 0x050a0000)
to space 4032K, 0% used [0x048c0000, 0x048c0000, 0x04cb0000)
tenured generation total 483968K, used 7518K [0x07800000, 0x250a0000, 0x42940000)
the space 483968K, 1% used [0x07800000, 0x07f57958, 0x07f57a00, 0x250a0000)
compacting perm gen total 14080K, used 14016K [0x42940000, 0x43700000, 0x46940000)
the space 14080K, 99% used [0x42940000, 0x436f0320, 0x436f0400, 0x43700000)
No shared spaces configured.
Dynamic libraries:
0x00400000 - 0x0040f000 C:\Program Files\Apache Software Foundation\Tomcat 5.5\bin\tomcat5.exe
0x7c800000 - 0x7c8c0000 C:\WINDOWS\system32\ntdll.dll
0x77e40000 - 0x77f42000 C:\WINDOWS\system32\kernel32.dll
0x77380000 - 0x77411000 C:\WINDOWS\system32\USER32.dll
0x77c00000 - 0x77c48000 C:\WINDOWS\system32\GDI32.dll
0x77f50000 - 0x77feb000 C:\WINDOWS\system32\ADVAPI32.dll
0x77c50000 - 0x77cef000 C:\WINDOWS\system32\RPCRT4.dll
0x76f50000 - 0x76f63000 C:\WINDOWS\system32\Secur32.dll
0x77ba0000 - 0x77bfa000 C:\WINDOWS\system32\MSVCRT.dll
0x7c8d0000 - 0x7d0cf000 C:\WINDOWS\system32\SHELL32.dll
0x77da0000 - 0x77df2000 C:\WINDOWS\system32\SHLWAPI.dll
0x76290000 - 0x762ad000 C:\WINDOWS\system32\IMM32.DLL
0x77420000 - 0x77523000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_D8713E55\comctl32.dll
0x6d7c0000 - 0x6da10000 C:\Program Files\Java\jre1.6.0_07\bin\client\jvm.dll
0x76aa0000 - 0x76acd000 C:\WINDOWS\system32\WINMM.dll
0x7c340000 - 0x7c396000 C:\WINDOWS\system32\MSVCR71.dll
0x6d270000 - 0x6d278000 C:\Program Files\Java\jre1.6.0_07\bin\hpi.dll
0x76b70000 - 0x76b7b000 C:\WINDOWS\system32\PSAPI.DLL
0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_07\bin\verify.dll
0x6d310000 - 0x6d32f000 C:\Program Files\Java\jre1.6.0_07\bin\java.dll
0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_07\bin\zip.dll
0x6d570000 - 0x6d583000 C:\Program Files\Java\jre1.6.0_07\bin\net.dll
0x71c00000 - 0x71c17000 C:\WINDOWS\system32\WS2_32.dll
0x71bf0000 - 0x71bf8000 C:\WINDOWS\system32\WS2HELP.dll
0x71b20000 - 0x71b61000 C:\WINDOWS\system32\mswsock.dll
0x5f270000 - 0x5f2ca000 C:\WINDOWS\system32\hnetcfg.dll
0x71ae0000 - 0x71ae8000 C:\WINDOWS\System32\wshtcpip.dll
0x76ed0000 - 0x76efa000 C:\WINDOWS\system32\DNSAPI.dll
0x76f70000 - 0x76f77000 C:\WINDOWS\System32\winrnr.dll
0x76f10000 - 0x76f3e000 C:\WINDOWS\system32\WLDAP32.dll
0x76f80000 - 0x76f85000 C:\WINDOWS\system32\rasadhlp.dll
0x4a6a0000 - 0x4a6ac000 C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\CustomerInfoProxy.dll
0x77670000 - 0x777a9000 C:\WINDOWS\system32\ole32.dll
0x77d00000 - 0x77d8b000 C:\WINDOWS\system32\OLEAUT32.dll
0x7c420000 - 0x7c4a7000 C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_E6967989\MSVCP80.dll
0x78130000 - 0x781cb000 C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_E6967989\MSVCR80.dll
0x777b0000 - 0x77833000 C:\WINDOWS\system32\CLBCatQ.DLL
0x77010000 - 0x770d6000 C:\WINDOWS\system32\COMRes.dll
0x77b90000 - 0x77b98000 C:\WINDOWS\system32\VERSION.dll
0x75da0000 - 0x75e5d000 C:\WINDOWS\system32\SXS.DLL
0x75e60000 - 0x75e87000 C:\WINDOWS\system32\apphelp.dll
0x4dc30000 - 0x4dc5e000 C:\WINDOWS\system32\msctfime.ime
0x4b0d0000 - 0x4b395000 C:\WINDOWS\system32\xpsp2res.dll
0x71bb0000 - 0x71bb9000 C:\WINDOWS\system32\WSOCK32.dll
0x4bbe0000 - 0x4bbea000 C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\ClearTranProxy.dll
0x745e0000 - 0x7489e000 C:\WINDOWS\system32\msi.dll
0x71c40000 - 0x71c97000 C:\WINDOWS\system32\NETAPI32.dll
0x4bc50000 - 0x4bc6c000 C:\WINDOWS\system32\DBNETLIB.DLL
0x71f60000 - 0x71f64000 C:\WINDOWS\system32\security.dll
0x76c90000 - 0x76cb7000 C:\WINDOWS\system32\msv1_0.dll
0x76cf0000 - 0x76d0a000 C:\WINDOWS\system32\iphlpapi.dll
0x761b0000 - 0x76243000 C:\WINDOWS\system32\crypt32.dll
0x76190000 - 0x761a2000 C:\WINDOWS\system32\MSASN1.dll
0x4bcf0000 - 0x4bcff000 C:\Program Files\Common Files\System\Ole DB\SQLOLEDB.RLL
0x4a8a0000 - 0x4a8aa000 C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\MIGI.DLL
0x73570000 - 0x736c2000 C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\MSVBVM60.DLL
0x4a950000 - 0x4a9e2000 C:\Program Files\Common Files\System\ado\msado15.dll
0x74a50000 - 0x74a6a000 C:\WINDOWS\system32\MSDART.DLL
0x4c850000 - 0x4c8c9000 C:\Program Files\Common Files\System\Ole DB\oledb32.dll
0x4dbb0000 - 0x4dbc1000 C:\Program Files\Common Files\System\Ole DB\OLEDB32R.DLL
VM Arguments:
jvm_args: -Dcatalina.home=C:\Program Files\Apache Software Foundation\Tomcat 5.5 -Dcatalina.base=C:\Program Files\Apache Software Foundation\Tomcat 5.5 -Djava.endorsed.dirs=C:\Program Files\Apache Software Foundation\Tomcat 5.5\common\endorsed -Djava.io.tmpdir=C:\Program Files\Apache Software Foundation\Tomcat 5.5\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\logging.properties -Djava.library.path=C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib vfprintf -Xms512m -Xmx1024m
java_command: <unknown>
Launcher Type: generic
Environment Variables:
JAVA_HOME=C:\Program Files\Java\jdk1.6.0_07
[error occurred during error reporting (printing environment variables), id 0xc0000005]
--------------- S Y S T E M ---------------
OS: Windows Server 2003 family Build 3790 Service Pack 2
CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 2097151k(2097151k free), swap 4194303k(4194303k free)
vm_info: Java HotSpot(TM) Client VM (10.0-b23) for windows-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:14:11 by "java_re" with MS VC++ 7.1
time: Mon Dec 28 15:24:00 2009
elapsed time: 600 seconds -
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.
-EdArgh - 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 Hotspot Error: Access Violation, need help interpreting the log.
Hello. I'm a relatively new developer (previously an engineer), and so to start me off I was given the task of providing a JNI-enabled interface to some legacy licensing software (it's C++, we want Java). Now the functionality of JNI is not the problem I have. I HAD those types of problems but now I'm having a far more obscure problem that is absolutely stumping me.
It's a Hotspot error that I cannot get rid off... and I cannot find a clear bit of info on how to interpret them.
About the problem...first off this does not happen on my development machine, where it is isolated from other components in the end-product. The integration machine with the rest of the software runs fine with a "Dummy" version of my component, but we get errors when the real version is in use. I'd really appreciate any help in understanding these things, even if it is just some general pointers.
First off here is the log
# An unexpected error has been detected by HotSpot Virtual Machine:
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c82caa4, pid=5516, tid=4420
# Java VM: Java HotSpot(TM) Client VM (1.5.0_14-b03 mixed mode)
# Problematic frame:
# C [ntdll.dll+0x2caa4]
--------------- T H R E A D ---------------
Current thread (0x0aa1eaa0): JavaThread "btpool0-5" [_thread_in_native, id=4420]
siginfo: ExceptionCode=0xc0000005, reading address 0x00000004
Registers:
EAX=0x0b1a9a40, EBX=0x00030000, ECX=0x00001448, EDX=0x00000000
ESP=0x0c90e774, EBP=0x0c90e780, ESI=0x0b1a9a38, EDI=0x0b1aa000
EIP=0x7c82caa4, EFLAGS=0x00010246
Top of Stack: (sp=0x0c90e774)
0x0c90e774: 00030000 00000003 00030005 0c90e7b8
0x0c90e784: 7c833a2a 0b1a9a4c 0b1aa000 0c90e7ac
0x0c90e794: 00000000 00000477 00030178 00030000
0x0c90e7a4: 0ab2de05 0003015c 00000600 0afd0000
0x0c90e7b4: 00030178 0c90e9e4 7c82b5fb 04030000
0x0c90e7c4: 000023b8 000023ac 00000000 7c829fd6
0x0c90e7d4: 7c82a124 00031138 0c90ea04 7c82a0b8
0x0c90e7e4: 7c82a0fc 000001ba 00000000 7c829fd6
Instructions: (pc=0x7c82caa4)
0x7c82ca94: 63 02 00 8b 4e 0c 8d 46 08 8b 10 89 4d 08 8b 09
0x7c82caa4: 3b 4a 04 89 55 0c 0f 85 ae 4f 01 00 3b c8 0f 85
Stack: [0x0c8d0000,0x0c910000), sp=0x0c90e774, free space=249k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ntdll.dll+0x2caa4]
C [ntdll.dll+0x33a2a]
C [ntdll.dll+0x2b5fb]
C [MSVCRT.dll+0x1d08c]
C [verify.dll+0x4897]
C [verify.dll+0x19c6]
C [verify.dll+0x126b]
C [java.dll+0x3fb7]
V [jvm.dll+0x11d86a]
V [jvm.dll+0x78acb]
V [jvm.dll+0x78deb]
V [jvm.dll+0x78aaa]
V [jvm.dll+0xcb029]
V [jvm.dll+0xcbcc6]
V [jvm.dll+0xcbbac]
V [jvm.dll+0x82c7b]
j com.a.b.c.lmv.Factoralproducer.MeanManagerImpl.subscribe
(Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;
Lcom/a/b/c/lmv/baseFactoral/TopicExpressionType;Ljava/lang/Boolean;
Lorg/oasis_open/docs/wsrf/_2004/_06/wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;
Lorg/oasis_open/docs/
wsrf/_2004/_06/wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;
Lcom/a/b/c/lmv/Factoralproducer/MeanPolicyType;Ljavax/xml/datatype/XMLGregorianCalendar;
Lcom/a/b/c/lmv/types/ppoToken;)
Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;+231
j com.a.b.c.lmv.Factoralproducer.FactoralProducerImpl.subscribe
(Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;
Lcom/a/b/c/lmv/baseFactoral/TopicExpressionType;Ljava/lang/Boolean;Lorg/oasis_open/docs/wsrf/_2004/_06/
wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;Lorg/oasis_open/docs/
wsrf/_2004/_06/wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;Lcom/a/b/c/lmv
/Factoralproducer/MeanPolicyType;Ljavax/xml/datatype/XMLGregorianCalendar;Lcom/a/b/c/lmv/types/ppoToken;)
Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;+20
v ~StubRoutines::call_stub
V [jvm.dll+0x875dd]
V [jvm.dll+0xdfd96]
V [jvm.dll+0x874ae]
V [jvm.dll+0xf3f82]
V [jvm.dll+0xa5752]
C [java.dll+0x6d4f]
j sun.reflect.NativeMethodAccepporImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
J sun.reflect.DelegatingMethodAccepporImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(Lorg/apache/cxf/message/Exchange;
Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+57
j org.apache.cxf.service.invoker.AbstractInvoker.invoke(Lorg/apache/cxf/message/Exchange;Ljava/lang/Object;
Ljava/lang/reflect/Method;Ljava/util/List;)Ljava/lang/Object;+26
j org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(Lorg/apache/cxf/message/Exchange;Ljava/lang/Object
;Ljava/lang/reflect/Method;Ljava/util/List;)Ljava/lang/Object;+179
j org.apache.cxf.service.invoker.AbstractInvoker.invoke(Lorg/apache/cxf/message/Exchange;Ljava/lang/Object;)
Ljava/lang/Object;+114
j org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run()V+26
j org.apache.cxf.workqueue.SynchronousExecutor.execute(Ljava/lang/Runnable;)V+1
j org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Lorg/apache/cxf/message/Message;)V+94
j org.apache.cxf.phase.PhaseInterceptorChain.dcntercept(Lorg/apache/cxf/message/Message;)Z+76
j org.apache.cxf.transport.ChainInitiationObserver.onMessage(Lorg/apache/cxf/message/Message;)V+137
j org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;)V+334
j org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;)V+341
j org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+47
j org.mortbay.jetty.handler.ContextHandler.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+700
j org.mortbay.jetty.handler.ContextHandlerCollection.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+272
j org.mortbay.jetty.handler.HandlerWrapper.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+23
j org.mortbay.jetty.Server.handle(Lorg/mortbay/jetty/HttpConnection;)V+110
j org.mortbay.jetty.HttpConnection.handleRequest()V+131
J org.mortbay.jetty.HttpParser.parseNext()J
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j org.mortbay.jetty.HttpParser.parseAvailable()J+1
j org.mortbay.jetty.HttpConnection.handle()V+122
j org.mortbay.jetty.bio.SocketConnector$Connection.run()V+130
j org.mortbay.jetty.security.SslSocketConnector$SslConnection.run()V+51
j org.mortbay.thread.BoundedThreadPool$PoolThread.run()V+45
v ~StubRoutines::call_stub
V [jvm.dll+0x875dd]
V [jvm.dll+0xdfd96]
V [jvm.dll+0x874ae]
V [jvm.dll+0x8720b]
V [jvm.dll+0xa2089]
V [jvm.dll+0x1112e8]
V [jvm.dll+0x1112b6]
C [MSVCRT.dll+0x2b530]
C [kernel32.dll+0x24829]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.a.b.c.lmv.Factoralproducer.MeanManagerImpl.subscribe
(Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;Lcom/a/b/c/lmv/baseFactoral/TopicExpressionType;
Ljava/lang/Boolean;Lorg/oasis_open/docs/wsrf/_2004/_06/wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;
Lorg/oasis_open/docs/
wsrf/_2004/_06/wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;Lcom/a/b/c/lmv/Factoralproducer/MeanPolicyType;
Ljavax/xml/datatype/XMLGregorianCalendar;Lcom/a/b/c/lmv/types/ppoToken;)
Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;+231
j com.a.b.c.lmv.Factoralproducer.FactoralProducerImpl.subscribe
(Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;Lcom/a/b/c/lmv/baseFactoral/TopicExpressionType;
Ljava/lang/Boolean;Lorg/oasis_open/docs/wsrf/_2004/_06/wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;
Lorg/oasis_open/docs/
wsrf/_2004/_06/wsrf_ws_resourceproperties_1_2_draft_01/QueryExpressionType;Lcom/a/b/c/lmv/Factoralproducer
/MeanPolicyType;Ljavax/xml/datatype/XMLGregorianCalendar;Lcom/a/b/c/lmv/types/ppoToken;)
Lorg/xmlbp/schemas/ws/_2003/_03/addressing/EndpcntReferenceType;+20
v ~StubRoutines::call_stub
j sun.reflect.NativeMethodAccepporImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)
Ljava/lang/Object;+0
j sun.reflect.NativeMethodAccepporImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87
J sun.reflect.DelegatingMethodAccepporImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(Lorg/apache/cxf/message/
Exchange;Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+57
j org.apache.cxf.service.invoker.AbstractInvoker.invoke(Lorg/apache/cxf/message/Exchange;
Ljava/lang/Object;Ljava/lang/reflect/Method;Ljava/util/List;)Ljava/lang/Object;+26
j org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(Lorg/apache/cxf/message/Exchange;
Ljava/lang/Object;Ljava/lang/reflect/Method;Ljava/util/List;)Ljava/lang/Object;+179
j org.apache.cxf.service.invoker.AbstractInvoker.invoke(Lorg/apache/cxf/message/Exchange;Ljava/lang/Object;)
Ljava/lang/Object;+114
j org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run()V+26
j org.apache.cxf.workqueue.SynchronousExecutor.execute(Ljava/lang/Runnable;)V+1
j org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Lorg/apache/cxf/message/Message;)V+94
j org.apache.cxf.phase.PhaseInterceptorChain.dcntercept(Lorg/apache/cxf/message/Message;)Z+76
j org.apache.cxf.transport.ChainInitiationObserver.onMessage(Lorg/apache/cxf/message/Message;)V+137
j org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;)V+334
j org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;)V+341
j org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+47
j org.mortbay.jetty.handler.ContextHandler.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+700
j org.mortbay.jetty.handler.ContextHandlerCollection.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+272
j org.mortbay.jetty.handler.HandlerWrapper.handle(Ljava/lang/String;Ljavax/servlet/http/HttpServletRequest;
Ljavax/servlet/http/HttpServletResponse;I)V+23
j org.mortbay.jetty.Server.handle(Lorg/mortbay/jetty/HttpConnection;)V+110
j org.mortbay.jetty.HttpConnection.handleRequest()V+131
J org.mortbay.jetty.HttpParser.parseNext()J
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j org.mortbay.jetty.HttpParser.parseAvailable()J+1
j org.mortbay.jetty.HttpConnection.handle()V+122
j org.mortbay.jetty.bio.SocketConnector$Connection.run()V+130
j org.mortbay.jetty.security.SslSocketConnector$SslConnection.run()V+51
j org.mortbay.thread.BoundedThreadPool$PoolThread.run()V+45
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x0aa2d9f8 JavaThread "RMI RenewClean-[47.166.94.29:3617]" daemon [_thread_in_native, id=4792]
=>0x0aa1eaa0 JavaThread "btpool0-5" [_thread_in_native, id=4420]
0x0aa1c450 JavaThread "btpool0-4" [_thread_in_native, id=4600]
0x0aa574d0 JavaThread "btpool0-3" [_thread_in_native, id=3456]
0x0aa61c60 JavaThread "RMI ConnectionExpiration-[localhost:8099]" daemon [_thread_blocked, id=5060]
0x0aa44988 JavaThread "btpool0-2" [_thread_in_native, id=3956]
0x0aa2f270 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=4640]
0x0aa2e668 JavaThread "RMI TCP Connection(1)-47.166.94.29" daemon [_thread_in_native, id=1600]
0x0aa40d48 JavaThread "RMI Reaper" [_thread_blocked, id=4696]
0x0b20ae68 JavaThread "Timer-0" daemon [_thread_blocked, id=4688]
0x0aa294f8 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=4884]
0x0aa29680 JavaThread "RMI ConnectionExpiration-[47.166.94.29:4375]" daemon [_thread_blocked, id=4860]
0x0abfe318 JavaThread "btpool0-1" [_thread_in_native, id=716]
0x0ac2b1f0 JavaThread "GC Daemon" daemon [_thread_blocked, id=3588]
0x0ac26730 JavaThread "RMI RenewClean-[47.166.94.29:4375]" daemon [_thread_blocked, id=1820]
0x0ab92d70 JavaThread "btpool1-0 - Acceptor0 [email protected]:9082" [_thread_in_native, id=3168]
0x0b162be0 JavaThread "btpool0-0 - Acceptor0 [email protected]:9080" [_thread_in_native, id=5856]
0x0b0e7a18 JavaThread "RMManager-Timer-12388840" daemon [_thread_blocked, id=4328]
0x00035088 JavaThread "DestroyJavaVM" [_thread_blocked, id=4780]
0x0afc6460 JavaThread "Thread-1" [_thread_blocked, id=440]
0x0afd6768 JavaThread "Thread-0" daemon [_thread_blocked, id=4840]
0x00814cc8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3076]
0x00813950 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3248]
0x00812cc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5140]
0x00809bf8 JavaThread "Finalizer" daemon [_thread_blocked, id=3704]
0x00808780 JavaThread "Reference Handler" daemon [_thread_blocked, id=5196]
Other Threads:
0x00804530 VMThread [id=736]
0x00816058 WatcherThread [id=4436]
VM state:not at safepcnt (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 1984K, used 1897K [0x02850000, 0x02a70000, 0x02d30000)
*eden space 1792K, 95% used [0x02850000, 0x029fa418, 0x02a10000)*
* from space 192K, 100% used [0x02a40000, 0x02a70000, 0x02a70000)*
to space 192K, 0% used [0x02a10000, 0x02a10000, 0x02a40000)
tenured generation total 25896K, used 18178K [0x02d30000, 0x0467a000, 0x06850000)
the space 25896K, 70% used [0x02d30000, 0x03ef0b60, 0x03ef0c00, 0x0467a000)
compacting perm gen total 22784K, used 22721K [0x06850000, 0x07e90000, 0x0a850000)
* the space 22784K, 99% used [0x06850000, 0x07e806c8, 0x07e80800, 0x07e90000)*
No shared spaces configured.
Dynamic libraries:
0x00400000 - 0x0040d000 D:\apps\Java\jre1.5.0_14\bin\java.exe
0x7c800000 - 0x7c8c0000 C:\WINDOWS\system32\ntdll.dll
0x77e40000 - 0x77f42000 C:\WINDOWS\system32\kernel32.dll
0x77f50000 - 0x77feb000 C:\WINDOWS\system32\ADVAPI32.dll
0x77c50000 - 0x77cef000 C:\WINDOWS\system32\RPCRT4.dll
0x76f50000 - 0x76f63000 C:\WINDOWS\system32\Secur32.dll
0x77ba0000 - 0x77bfa000 C:\WINDOWS\system32\MSVCRT.dll
0x6d640000 - 0x6d7de000 D:\apps\Java\jre1.5.0_14\bin\client\jvm.dll
0x77380000 - 0x77411000 C:\WINDOWS\system32\USER32.dll
0x77c00000 - 0x77c48000 C:\WINDOWS\system32\GDI32.dll
0x76aa0000 - 0x76acd000 C:\WINDOWS\system32\WINMM.dll
0x71bc0000 - 0x71bc8000 C:\WINDOWS\system32\rdpsnd.dll
0x771f0000 - 0x77201000 C:\WINDOWS\system32\WINSTA.dll
0x71c40000 - 0x71c97000 C:\WINDOWS\system32\NETAPI32.dll
0x76b70000 - 0x76b7b000 C:\WINDOWS\system32\PSAPI.DLL
0x6d290000 - 0x6d298000 D:\apps\Java\jre1.5.0_14\bin\hpi.dll
0x6d610000 - 0x6d61c000 D:\apps\Java\jre1.5.0_14\bin\verify.dll
0x6d310000 - 0x6d32d000 D:\apps\Java\jre1.5.0_14\bin\java.dll
0x6d630000 - 0x6d63f000 D:\apps\Java\jre1.5.0_14\bin\zip.dll
0x68000000 - 0x68035000 C:\WINDOWS\system32\rsaenh.dll
0x7c8d0000 - 0x7d0cf000 C:\WINDOWS\system32\SHELL32.dll
0x77da0000 - 0x77df2000 C:\WINDOWS\system32\SHLWAPI.dll
0x77420000 - 0x77523000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls
_6595b64144ccf1df_6.0.3790.3959_x-ww_D8713E55\comctl32.dll
0x6d4d0000 - 0x6d4e3000 D:\apps\Java\jre1.5.0_14\bin\net.dll
0x71c00000 - 0x71c17000 C:\WINDOWS\system32\WS2_32.dll
0x71bf0000 - 0x71bf8000 C:\WINDOWS\system32\WS2HELP.dll
0x71b20000 - 0x71b61000 C:\WINDOWS\System32\mswsock.dll
0x76ed0000 - 0x76efa000 C:\WINDOWS\system32\DNSAPI.dll
0x76f70000 - 0x76f77000 C:\WINDOWS\System32\winrnr.dll
0x76f10000 - 0x76f3e000 C:\WINDOWS\system32\WLDAP32.dll
0x76f80000 - 0x76f85000 C:\WINDOWS\system32\rasadhlp.dll
0x5f270000 - 0x5f2ca000 C:\WINDOWS\system32\hnetcfg.dll
0x71ae0000 - 0x71ae8000 C:\WINDOWS\System32\wshtcpip.dll
0x6d4f0000 - 0x6d4f9000 D:\apps\Java\jre1.5.0_14\bin\nio.dll
0x6d5f0000 - 0x6d5f6000 D:\apps\Java\jre1.5.0_14\bin\rmi.dll
0x10000000 - 0x10006000 C:\Program Files\a\lmv\punix.dll
0x71f50000 - 0x71f58000 C:\WINDOWS\system32\snmpapi.dll
0x0bb90000 - 0x0bb98000 C:\Program Files\a\lmv\periwin.dll
0x0bba0000 - 0x0bbab000 C:\Program Files\a\lmv\vas.dll
0x0bbb0000 - 0x0bbd0000 C:\Program Files\a\lmv\nilm.dll
0x48890000 - 0x488cd000 C:\WINDOWS\system32\ODBC32.dll
0x77530000 - 0x775c7000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls
_6595b64144ccf1df_5.82.3790.3959_x-ww_78FCF8D0\COMCTL32.dll
0x762b0000 - 0x762f9000 C:\WINDOWS\system32\comdlg32.dll
0x76cf0000 - 0x76d0a000 C:\WINDOWS\system32\iphlpapi.dll
0x7f010000 - 0x7f134000 C:\WINDOWS\system32\MFC42u.DLL
0x77670000 - 0x777a9000 C:\WINDOWS\system32\ole32.dll
0x77d00000 - 0x77d8b000 C:\WINDOWS\system32\OLEAUT32.dll
0x77210000 - 0x772bb000 C:\WINDOWS\system32\WININET.dll
0x761b0000 - 0x76243000 C:\WINDOWS\system32\CRYPT32.dll
0x76190000 - 0x761a2000 C:\WINDOWS\system32\MSASN1.dll
0x71bb0000 - 0x71bb9000 C:\WINDOWS\system32\WSOCK32.dll
0x0bda0000 - 0x0bdb7000 C:\WINDOWS\system32\odbcint.dll
0x0bf20000 - 0x0bf61000 C:\Program Files\a\lmv\JniLib.dll
0x76cd0000 - 0x76ce9000 C:\WINDOWS\system32\MPRAPI.dll
0x76df0000 - 0x76e24000 C:\WINDOWS\system32\ACTIVEDS.dll
0x76dc0000 - 0x76de8000 C:\WINDOWS\system32\adsldpc.dll
0x76b80000 - 0x76bae000 C:\WINDOWS\system32\credui.dll
0x76a80000 - 0x76a98000 C:\WINDOWS\system32\ATL.DLL
0x76e30000 - 0x76e3c000 C:\WINDOWS\system32\rtutils.dll
0x7e020000 - 0x7e02f000 C:\WINDOWS\system32\SAMLIB.dll
0x770e0000 - 0x771e8000 C:\WINDOWS\system32\SETUPAPI.dll
0x77840000 - 0x77882000 C:\WINDOWS\system32\netman.dll
0x76300000 - 0x764c0000 C:\WINDOWS\system32\netshell.dll
0x74de0000 - 0x74df2000 C:\WINDOWS\system32\CLUSAPI.dll
0x76e90000 - 0x76ecf000 C:\WINDOWS\system32\RASAPI32.dll
0x76e40000 - 0x76e52000 C:\WINDOWS\system32\rasman.dll
0x76e60000 - 0x76e8f000 C:\WINDOWS\system32\TAPI32.dll
0x7fcf0000 - 0x7fd7e000 C:\WINDOWS\system32\WZCSvc.DLL
0x76cc0000 - 0x76cc5000 C:\WINDOWS\system32\WMI.dll
0x76d10000 - 0x76d2f000 C:\WINDOWS\system32\DHCPCSVC.DLL
0x76f00000 - 0x76f08000 C:\WINDOWS\system32\WTSAPI32.dll
0x4b180000 - 0x4b284000 C:\WINDOWS\system32\ESENT.dll
0x730a0000 - 0x730ae000 C:\WINDOWS\system32\WZCSAPI.DLL
VM Arguments:
java_command: C:\Program Files\a\lmv\CDF\b_c_lmv.jar C:\Program Files\a\lmv\CDF
Launcher Type: SUN_STANDARD
Environment Variables:
CLASSPATH=D:\a\Contact Center\Common Components\Cache\lib
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;
C:\Program Files\Rational\ClearCase\bin;C:\Program Files\Rational\common;
C:\a\Cache\CacheSys\Mgr\a\DLL;C:\Program Files\a\lmv\TAPI;C:\Program Files\a\lmv\
OS=Windows_NT
PROCEppoR_IDENTIFIER=x86 Family 6 Model 15 Stepping 11, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows Server 2003 family Build 3790 Service Pack 2
CPU:total 4 (cores per cpu 4, threads per core 1) family 6 model 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2
Memory: 4k page, physical 2097151k(2097151k free), swap 4194303k(3537076k free)
vm_info: Java HotSpot(TM) Client VM (1.5.0_14-b03) for windows-x86, built on Oct 5 2007 01:21:52 by "java_re" with MS VC++ 6.0
{code}
Sorry it's so long.
Anyways my dll is Jni_interface.dll. It loads legacy.dll, and its dependents. Other code also uses these libraries.
*So question 1* :
I load the jni_interface.dll (and also the legacy.dll and its dependents) library at the start of execution in a static class and so it is never unloaded. I do this because the legacy.dll will be calling functions in my Jni_Interface.dll, which are propagated into the Java class on top of it all. Does this stop other code from loading the legacy.dll or from using its functionality?
*On to question 2*:
Here is the logged output from my library, immediately before the crash:
{code:java}
*** JNI INTERFACE LIB - LOG 21 Jul 08 19:11:35.682 *** Log Level = DEBUG
21 Jul 08 19:11:35.698 - Level[ info ] - Thread[ 716 ] :: initRegistry Registry initialisation ok
21 Jul 08 19:11:35.760 - Level[ info ] - Thread[ 716 ] :: vPersistData vPersistData() called
21 Jul 08 19:11:35.823 - Level[ debug ] - Thread[ 716 ] :: doVoidCallback() [ persistDataHandler ] Signature = (I)V
21 Jul 08 19:11:35.823 - Level[ debug ] - Thread[ 716 ] :: doVoidCallback() [ setMaxUsageHandler ] Signature = (I)V
21 Jul 08 19:11:35.838 - Level[ info ] - Thread[ 716 ] :: Constructor _instance is instantiated
21 Jul 08 19:11:35.838 - Level[ info ] - Thread[ 716 ] :: initiateLegacy() JniManager initialisation successful
21 Jul 08 19:11:35.838 - Level[ info ] - Thread[ 716 ] :: initiateLegacy() Initial state is NORMAL
21 Jul 08 19:11:35.838 - Level[ debug ] - Thread[ 716 ] :: getLicense() Get request
21 Jul 08 19:11:36.010 - Level[ debug ] - Thread[ 716 ] :: getLicense() Get request
{code}
Now notice that the current thread in the Hotspot output is NOT the thread in my library. Thread 716 is a java thread by the way. This log appears absolutely fine according to me. Also note that in the hotspot log there is no mention of my java component (the "boss" class), which is called LegacyLM. So does that mean that is in not to do with my code even though the problem only occurs when my component is included? Or is this just the cryptic nature of these problems?
*Question 3*:
If you see the heap section of the report, there are 3 items that I have highlighted that seem like very high values. Is this a possible cause of a crash? Or would I have received an "Out of space" error instead?
In terms of actual code, I cannot post much, but I can tell you what I have done to try to solve the problem:
(i) I have added mutex synchronisation to most of my shared variables.
(ii) I have used monitorEnter and MonitorExit to control callback access to my java class.
(iii) I have re-organised my code and replaced nearly every occurance of non-string character arrays with string equivalents.
(iv) I changed how I attach and detach my threads so that I only attach/detach ones that previously were not (i.e. I leave java threads alone)
As I said at the start, I am utterly confused and I don't have much of an idea about how to proceed. I'd really really appreciate a pointer or two.
Thanks in advance.
D
Edited by: Diom1982 on Jul 21, 2008 12:35 PM
Edited by: Diom1982 on Jul 21, 2008 12:40 PMFor those of you who might be interested, I found a solution to this problem (my version, at least). In my situation, this was caused by attempting to access the fields of a ActionEvent object in VC++ by casting a variant to a BSTR. While the cast "worked", it somehow caused the state of the Java plugin or the AxBridge DLL to get flummoxed, causing the VM dump far downstream.
The takehome message?
When seeing problems like this in the plugin / ActiveX bridge, do not assume that the causative error is occuring in the location noted in the stack trace. Visual C++, in all of its gory unprotected glory, gives full memory access to the DLL interface and you can do a serious fandango on the VM core. that won't necessarily bite you until later.
PS -- Sun gurus ... does this present a security violation in the Java paradigm?
Maybe you are looking for
-
Scroll functionality Oracle forms 6i
Is possible to have scroll functionality in Oracle forms 6i. I searched , but iam getting only posts pointing to install external freewares like FREEWHEEL.exe to have the scroll functionality is it possible to configure any existing functionality , S
-
I shoot ijn Camera RAW on a Canon 5D2 in LR3 and I'm having colour issues; skin tones are often purple/magenta tinted and very difficult to correct. I usually set the WB to Custom and shoot a grey card and set the picture style on the camera to Neutr
-
Auto organizing the order of photos
I brought in a few hundred stills made with DVKitchen ... pulled from a film and given a chronological sequence of numbers. But the order in Aperture doesn't follow the chronology; the stills are ordered randomly it seems. I'm sure there is a click
-
I am trying to run the following code which shold spit out my table in an XML format. But I keep getting the same error!. Thanks in advance! SQL> SELECT XMLQuery('for $c in ora:view("CUCODES") 2 return $c' RETURNING CONTENT) FROM DUAL; return $c' RET
-
OAD.exe error (Dr Watsons Error on NT)
I have successfully installed the Master Discoverer (3i) on an NT server. But whenever I logout from the server and log back in, I notice an "oad.exe" application error and the application doesn't work unitl I start all the services again. This probl