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
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
Re: Win7 calling native code via JNI
Caldarale, Charles R chuck.caldar...@unisys.com 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
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 billwbar...@verizon.net Sent: Saturday, March 27, 2010 7:45 PM To: users@tomcat.apache.org Subject: Re: Win7 calling native code via JNI Caldarale, Charles R chuck.caldar...@unisys.com 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
