Re: Win7 calling native code via JNI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patrick,
On 3/27/2010 9:07 PM, Patrick Flaherty wrote:
> There is only a 32 bit JVM on the machine. The bridge dll has not been
> recompiled since
> mid '08. If it was an incompatibility with the Microsoft Runtime
> Library wouldn't you expect
> the Service Version to do the same ?
It's possible that different libraries are being picked-up in the two
different environments (system service vs. your own account). Is this
the file you expected to get?
C:\Windows\syswow64\msvcrt.dll
If you look at the code you will see I try to create a file on the
root of the C drive (remotedebug.txt) and
>
> The file does get created via the Service but not standalone, weird.
> If it was crashing as a result of the file creation, would you expect
> to see the CPPinit at the top of the stack trace ?
I see your Java method cppInit at the top of the stack trace, but I
can't tell what is happening once your library is running. RRBridge.dll
appears twice on the stack in the backtrace with no debugging
information, but you can at least tell that your DDL is calling itself
at some point.
Your file won't get created at all given this line:
//FILE *fp = fopen("C:\\remotedebug.txt", "at");
...but your cppInit method does make these calls (presumably to other
functions in your library):
RSWP_DBL (looks like a macro)
RSWP_Volumes
RSWP_CheckHasp
RSWP_SetDataBase
What debugging information gets emitted before the crash? Is your debug
logger set to auto-flush? If not, you could be missing crucial logging
information that occurred just before the crash.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuwsZwACgkQ9CaO5/Lv0PDFPQCdHTkZpKCO8YDfDq6HuEtDWEKG
ARwAn07wq6r0Ici/BBbh3krgv6MeTdat
=U/UC
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Win7 calling native code via JNI
There is only a 32 bit JVM on the machine. The bridge dll has not been recompiled since mid '08. If it was an incompatibility with the Microsoft Runtime Library wouldn't you expect the Service Version to do the same ? If you look at the code you will see I try to create a file on the root of the C drive (remotedebug.txt) and The file does get created via the Service but not standalone, weird. If it was crashing as a result of the file creation, would you expect to see the CPPinit at the top of the stack trace ? Thanks again -- From: "Bill Barker" Sent: Saturday, March 27, 2010 7:45 PM To: Subject: Re: Win7 calling native code via JNI "Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f96d2507...@usea-exch8.na.uis.unisys.com... From: Patrick Flaherty [mailto:pflah...@rampageinc.com] Subject: Win7 calling native code via JNI as soon as I call the dll's init function (CPPInit) it crashed the JVM. Are you using the same JVM when you run Tomcat as a service? The one in this crash is the 32-bit client, but you're on a 64-bit platform, and I wouldn't be surprised that the service is using a 64-bit server JVM (assuming you have one installed). It wouldn't even get that far if he tried to load a 32-bit dll in a 64-bit JVM. My guess is an incompatibility in the MSVCRT.dll versions. If you compile the JNI dll with a newer version of MSVC, then you can see weird crashes like this. If you look at the code you will see I try to create a file on the root of the C drive (remotedebug.txt) and Does the account you're running on have permission to do that? (Win7 is a tad picky about things like that.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Win7 calling native code via JNI
"Caldarale, Charles R" wrote in message news:99c8b2929b39c24493377ac7a121e21f96d2507...@usea-exch8.na.uis.unisys.com... From: Patrick Flaherty [mailto:pflah...@rampageinc.com] Subject: Win7 calling native code via JNI as soon as I call the dll's init function (CPPInit) it crashed the JVM. Are you using the same JVM when you run Tomcat as a service? The one in this crash is the 32-bit client, but you're on a 64-bit platform, and I wouldn't be surprised that the service is using a 64-bit server JVM (assuming you have one installed). It wouldn't even get that far if he tried to load a 32-bit dll in a 64-bit JVM. My guess is an incompatibility in the MSVCRT.dll versions. If you compile the JNI dll with a newer version of MSVC, then you can see weird crashes like this. If you look at the code you will see I try to create a file on the root of the C drive (remotedebug.txt) and Does the account you're running on have permission to do that? (Win7 is a tad picky about things like that.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Win7 calling native code via JNI
> From: Patrick Flaherty [mailto:pflah...@rampageinc.com] > Subject: Win7 calling native code via JNI > as soon as I call the dll's init function > (CPPInit) it crashed the JVM. Are you using the same JVM when you run Tomcat as a service? The one in this crash is the 32-bit client, but you're on a 64-bit platform, and I wouldn't be surprised that the service is using a 64-bit server JVM (assuming you have one installed). > If you look at the code you will see I try to create a file on the > root of the C drive (remotedebug.txt) and Does the account you're running on have permission to do that? (Win7 is a tad picky about things like that.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Win7 calling native code via JNI
Hello,
I have a ROOT webapp running in "Tomcat 6.0.20 as a SERVICE" on
Windows 7 and it runs fine calling native code via JNI.
Now for debugging purposes :
I'm trying to run it with tomcat not running as a service (tomcat
started via startup.bat) and the load
of my bridge dll is ok, but as soon as I call the dll's init function
(CPPInit) it crashed the JVM.
If you look at the code you will see I try to create a file on the
root of the C drive (remotedebug.txt) and
this file never gets created but I don't think that is what is
causing the crash as CPPInit is called after
this file create and CPPInit seems to be what's failing.
See Code and JVM crash below.
Native Code Header:
/*
* Class: com_companyinc_direct_remote_bridge_RLBridge
* Method:cppInit
* Signature: (Ljava/lang/String;Ljava/lang/String;I[I)I
*/
JNIEXPORT jint JNICALL
Java_com_companyinc_direct_remote_bridge_RLBridge_cppInit
(JNIEnv *, jobject, jstring, jstring, jint, jintArray);
Native Code:
JNIEXPORT jint JNICALL
Java_com_companyinc_direct_remote_bridge_RLBridge_cppInit
(JNIEnv *env, jobject obj, jstring rdb, jstring jdb, jint dbl,
jintArray rtn)
{
int result;
int version;
jint *rtn_array;
wchar_t *rdb_str = (wchar_t *)env->GetStringChars(rdb, 0);
wchar_t *jdb_str = (wchar_t *)env->GetStringChars(jdb, 0);
rtn_array = env->GetIntArrayElements(rtn, FALSE);
const char *s1 = env->GetStringUTFChars(rdb, NULL);
const char *s2 = env->GetStringUTFChars(jdb, NULL);
//FILE *fp = fopen("C:\\remotedebug.txt", "at");
dbgout("CPP:Initializing bridge...");
dbgout(s1);
dbgout(s2);
//dbgout(rdb_str);
//dbgout(jdb_str);
// Turn on debugging stuff so we can see it...remember to turn this
off later!
RSWP_DBL(dbl);
dbgout("CPP:Debugging intialized.\n");
result = RSWP_Volumes(rdb_str, jdb_str, &version);
//result = rswpINVALID;
rtn_array[0] = version;
dbgout("CPP:Bridge Initialized.\n");
env->ReleaseStringChars(rdb, rdb_str);
env->ReleaseStringChars(jdb, jdb_str);
env->ReleaseIntArrayElements(rtn, rtn_array, 0);
// Ok, now, we have to dig deeper if there's an error
if (result == 2) // 2 means Dongle_INVALID, which is a catch-all for
Paul
{
// Is this ACTUALLY a dongle error?
if (RSWP_CheckHasp(TRUE) == 0)
{
// THis really isn't a HASP error, is it a DB error?
if (RSWP_SetDataBase(TRUE, NULL, 0) == 0)
{
// Not a DB error either, let's return the
WHO_KNOWS error (9)
result = 9;
}
else
{
// This is indeed a DB error, set the right
result
result = 4;
}
}
}
JVM CRASH:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x77c42272,
pid=2804, tid=3128
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Client VM (16.0-b13 mixed mode, sharing
windows-x86 )
# Problematic frame:
# C [ntdll.dll+0x22272]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--- T H R E A D ---
Current thread (0x050e5400): JavaThread "http-80-3" daemon
[_thread_in_native, id=3128, stack(0x05df,0x05e4)]
siginfo: ExceptionCode=0xc005, writing address 0x0024
Registers:
EAX=0x0024, EBX=0x349ec398, ECX=0x05b5c5f8, EDX=0x0005
ESP=0x05e3f578, EBP=0x05e3f58c, ESI=0x0024, EDI=0x0020
EIP=0x77c42272, EFLAGS=0x00010202
Top of Stack: (sp=0x05e3f578)
0x05e3f578: 050e5400 05b52eae 05b5c658
0x05e3f588: 05b5c034 05e3f5c0 05b52d56 0020
0x05e3f598: 05b52e56 050e5400 349ec398
0x05e3f5a8: 349ec398 05b5104a 05b5c048
0x05e3f5b8: 05b5c04c 05e3f5e8 05b510c2
0x05e3f5c8: 05b5c04c 04c911a0 050eb120 349ec398
0x05e3f5d8: 04cfc008 04c90fc0 04cfc428 000e5400
0x05e3f5e8: 05e3f634 02569f47 050e5510 05e3f654
Instructions: (pc=0x77c42272)
0x77c42262: 55 8b ec 83 ec 0c 56 57 8b 7d 08 8d 77 04 8b c6
0x77c42272: f0 0f ba 30 00 0f 83 5e 01 01 00 64 a1 18 00 00
Stack: [0x05df,0x05e4], sp=0x05e3f578, free space=13d05e3f05ck
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [ntdll.dll+0x22272]
C [RRBridge.dll+0x2d56]
C [RRBridge.dll+0x10c2]
j com.companyinc.direct.remote.bridge.RLBridge.cppInit(Ljava/lang/
String;L
