Problems to setup Juice with Windows
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
Problems to setup Juice with Windows
by Dittmann, Werner
::
Rate this Message:
All,
to get Juice running on Windows I need some help from Windows / Java gurus. The tests with a first version of Juice on Linux where successful. I tried to bring Juice onto a Windows Box as well, but I encoutered a strange problem. Here is what I did: - using cygwin I was able to setup the autoconf stuff, create a configure script, and compiled the native sources into a DLL. Before the compile was sucessful I copied the files "jni.h" and "jni_md.h" from the Java include directory to /usr/include of cygwin. Then I changed the "typedef __int64 jlong" to "typedef long long jint" to be compliant with gcc. - after creating the shared lib I extended PATH to point to the lib's directory and started a test. During System.load("openSSL4Java") I got no problems. Then I got an internal JVM error. See the code snippet that initializes the whole stuff (extracted from JCEBlockCipherOpenSSL.java): .... static { try { System.loadLibrary("openSSL4Java"); } catch (SecurityException se) { openSSLLoaded = false; if (log.isFatalEnabled()) { log.fatal("Security Exception while loading native library.", se); } } catch (UnsatisfiedLinkError le) { openSSLLoaded = false; if (log.isFatalEnabled()) { log.fatal("Unsatisfied Linke error while loading native library.", le); } } if (openSSLLoaded) { openSSL4Ready = InitializeOpenSSL.initialize(); } } ... The error happens during the call "InitializeOpenSSL.initialize()". Note that InitializeOpenSSL is a java class, not part of the shared lib. At that point in time no method of the shared lib was called from Juice's java code (except maybe internally during loading the lib). Here is the error text: # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d71ac12, pid=4008, tid=1380 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_03-b07 mixed mode) # Problematic frame: # V [jvm.dll+0x6ac12] # # An error report file with more information is saved as hs_err_pid4008.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I already tried to rename some methods and files because I thought the problem is because of name clashes or so - but no success. A more detailled info (the detailled error log) can be provided if necessary. All sources are in the SVN, also a signed juice.jar in the dist directory. Any ideas? Any help is appreciated. Regards, Werner --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
RE: Problems to setup Juice with Windows
by Scott Cantor
::
Rate this Message:
> - using cygwin I was able to setup the autoconf stuff, create a
> configure script, and compiled the native sources into a DLL. Before > the compile was sucessful I copied the files "jni.h" and "jni_md.h" > from the Java include directory to /usr/include of cygwin. Then I > changed the "typedef __int64 jlong" to "typedef long long jint" to > be compliant with gcc. Is cygwin the way people would want to use this? I somehow doubt it. Most people on Windows don't wish to pull in the cygwin DLLs, they want proper Windows builds. > Any ideas? Any help is appreciated. Regardless of the previous point, is there actual proof that the JVM can load native code built with cygwin? Maybe it just works, but I'd try and verify that independently before I went looking for root causes. -- Scott --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: Problems to setup Juice with Windows
by Berin Lautenbach
::
Rate this Message:
Having played with getting things running under Cygwin - I think I'd
tend to agree with Scott. It adds some extra complications into the build/run process that could well trip you up. Is it possible to get the stuff to compile on VC++? Are you open for me to have a look to see if I can get it up and running? Cheers, Berin Scott Cantor wrote: >>- using cygwin I was able to setup the autoconf stuff, create a >> configure script, and compiled the native sources into a DLL. Before >> the compile was sucessful I copied the files "jni.h" and "jni_md.h" >> from the Java include directory to /usr/include of cygwin. Then I >> changed the "typedef __int64 jlong" to "typedef long long jint" to >> be compliant with gcc. > > > Is cygwin the way people would want to use this? I somehow doubt it. Most > people on Windows don't wish to pull in the cygwin DLLs, they want proper > Windows builds. > > >>Any ideas? Any help is appreciated. > > > Regardless of the previous point, is there actual proof that the JVM can > load native code built with cygwin? Maybe it just works, but I'd try and > verify that independently before I went looking for root causes. > > -- Scott > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: Problems to setup Juice with Windows
by Raul Benito-2
::
Rate this Message:
I have compiled a long ago the juice dll for windows using mingw. It
has work OK, after changing the jni*.h like you do. I don't have access to my environment, but perhaps you can try with mingw.... Regards, Raul On 2/13/06, Scott Cantor <cantor.2@...> wrote: > > - using cygwin I was able to setup the autoconf stuff, create a > > configure script, and compiled the native sources into a DLL. Before > > the compile was sucessful I copied the files "jni.h" and "jni_md.h" > > from the Java include directory to /usr/include of cygwin. Then I > > changed the "typedef __int64 jlong" to "typedef long long jint" to > > be compliant with gcc. > > Is cygwin the way people would want to use this? I somehow doubt it. Most > people on Windows don't wish to pull in the cygwin DLLs, they want proper > Windows builds. > > > Any ideas? Any help is appreciated. > > Regardless of the previous point, is there actual proof that the JVM can > load native code built with cygwin? Maybe it just works, but I'd try and > verify that independently before I went looking for root causes. > > -- Scott > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > -- http://r-bg.com --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
|
|
|
|
|
|
Re: AW: Problems to setup Juice with Windows
by Berin Lautenbach
::
Rate this Message:
Just started having a look. Is see there is already a project file for
VC++ 6.0 in the old source directory. I'll set up something in the "standard" "Projects/..." folder structure to get it going. But first I'll get it running under Linux to see how it should work :>. Having an interesting time getting it to autoconf, but I'll work it out tomorrow night. Cheers, Berin Dittmann, Werner wrote: > Berin, > > sureI'm open to that. > > The whole native stuff is in plain C, just 5 modules > in C plus the headers. IMHO I don't use any stuff > that is Linux specific. > > The only prerequistite is the availabilty of the openSSL > headers and crypto lib. > > You can find the sources in incubator/juice/native/srcNew. > > If you have ides/questions just send a mail. > > Regards, > Werner > > >>-----Ursprüngliche Nachricht----- >>Von: Berin Lautenbach [mailto:berin@...] >>Gesendet: Dienstag, 14. Februar 2006 09:28 >>An: juice-dev@... >>Betreff: Re: Problems to setup Juice with Windows >> >>Having played with getting things running under Cygwin - I think I'd >>tend to agree with Scott. It adds some extra complications into the >>build/run process that could well trip you up. >> >>Is it possible to get the stuff to compile on VC++? Are you >>open for me >>to have a look to see if I can get it up and running? >> >>Cheers, >> Berin >> >>Scott Cantor wrote: >> >>>>- using cygwin I was able to setup the autoconf stuff, create a >>>> configure script, and compiled the native sources into a >> >>DLL. Before >> >>>> the compile was sucessful I copied the files "jni.h" and >> >>"jni_md.h" >> >>>> from the Java include directory to /usr/include of cygwin. Then I >>>> changed the "typedef __int64 jlong" to "typedef long long jint" to >>>> be compliant with gcc. >>> >>> >>>Is cygwin the way people would want to use this? I somehow >> >>doubt it. Most >> >>>people on Windows don't wish to pull in the cygwin DLLs, >> >>they want proper >> >>>Windows builds. >>> >>> >>> >>>>Any ideas? Any help is appreciated. >>> >>> >>>Regardless of the previous point, is there actual proof >> >>that the JVM can >> >>>load native code built with cygwin? Maybe it just works, >> >>but I'd try and >> >>>verify that independently before I went looking for root causes. >>> >>>-- Scott >>> >>> >>> >> >>--------------------------------------------------------------------- >> >>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>For additional commands, e-mail: juice-dev-help@... >>> >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>For additional commands, e-mail: juice-dev-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
|
|
|
Re: AW: AW: Problems to setup Juice with Windows
by Berin Lautenbach
::
Rate this Message:
The autogen problem was me Debian installing automake 1.4 by default(!)
Once I had 1.9 everything was cool. I have imported a *very* basic debug build for VC 6.0 into the repo. There are some interesting complile time messages that I will look at, but I get 21 tests run successfully before I get a rather nasty memory access violation. I'll sort that one out in a few days as well :>. Cheers, Berin Dittmann, Werner wrote: > Berin, > > this project file is for the old juice native software. Pls > be informed that I introduced a new setup for Juice. > > The autoconf under Linux should simply work. Have a look > the the configure.ac and tha Makefile.am files, but running > ./configure should work (if zou download the GZ file), otherwise > just run the autogen.sh script. This creates all necessary > files and runs ./configure. After "make" the shared lib > is in srcNew/.libs. > > Don't forget to set LD_LIBRARY_PATH correctly for the test > cases. > > Regards, > Werner > > > >>-----Ursprüngliche Nachricht----- >>Von: Berin Lautenbach [mailto:berin@...] >>Gesendet: Dienstag, 14. Februar 2006 10:27 >>An: juice-dev@... >>Betreff: Re: AW: Problems to setup Juice with Windows >> >>Just started having a look. Is see there is already a >>project file for >>VC++ 6.0 in the old source directory. I'll set up something in the >>"standard" "Projects/..." folder structure to get it going. >> >>But first I'll get it running under Linux to see how it >>should work :>. >> Having an interesting time getting it to autoconf, but I'll work it >>out tomorrow night. >> >>Cheers, >> Berin >> >>Dittmann, Werner wrote: >> >> >>>Berin, >>> >>>sureI'm open to that. >>> >>>The whole native stuff is in plain C, just 5 modules >>>in C plus the headers. IMHO I don't use any stuff >>>that is Linux specific. >>> >>>The only prerequistite is the availabilty of the openSSL >>>headers and crypto lib. >>> >>>You can find the sources in incubator/juice/native/srcNew. >>> >>>If you have ides/questions just send a mail. >>> >>>Regards, >>>Werner >>> >>> >>> >>>>-----Ursprüngliche Nachricht----- >>>>Von: Berin Lautenbach [mailto:berin@...] >>>>Gesendet: Dienstag, 14. Februar 2006 09:28 >>>>An: juice-dev@... >>>>Betreff: Re: Problems to setup Juice with Windows >>>> >>>>Having played with getting things running under Cygwin - I >> >>think I'd >> >>>>tend to agree with Scott. It adds some extra complications >> >>into the >> >>>>build/run process that could well trip you up. >>>> >>>>Is it possible to get the stuff to compile on VC++? Are you >>>>open for me >>>>to have a look to see if I can get it up and running? >>>> >>>>Cheers, >>>> Berin >>>> >>>>Scott Cantor wrote: >>>> >>>> >>>>>>- using cygwin I was able to setup the autoconf stuff, create a >>>>>>configure script, and compiled the native sources into a >>>> >>>>DLL. Before >>>> >>>> >>>>>>the compile was sucessful I copied the files "jni.h" and >>>> >>>>"jni_md.h" >>>> >>>> >>>>>>from the Java include directory to /usr/include of cygwin. Then I >>>>>>changed the "typedef __int64 jlong" to "typedef long >> >>long jint" to >> >>>>>>be compliant with gcc. >>>>> >>>>> >>>>>Is cygwin the way people would want to use this? I somehow >>>> >>>>doubt it. Most >>>> >>>> >>>>>people on Windows don't wish to pull in the cygwin DLLs, >>>> >>>>they want proper >>>> >>>> >>>>>Windows builds. >>>>> >>>>> >>>>> >>>>> >>>>>>Any ideas? Any help is appreciated. >>>>> >>>>> >>>>>Regardless of the previous point, is there actual proof >>>> >>>>that the JVM can >>>> >>>> >>>>>load native code built with cygwin? Maybe it just works, >>>> >>>>but I'd try and >>>> >>>> >>>>>verify that independently before I went looking for root causes. >>>>> >>>>>-- Scott >>>>> >>>>> >>>>> >>>> >>>>------------------------------------------------------------ >> >>--------- >> >>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>>> >>>> >>>>------------------------------------------------------------ >> >>--------- >> >>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>> >>> >>> >>--------------------------------------------------------------------- >> >>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>For additional commands, e-mail: juice-dev-help@... >>> >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>For additional commands, e-mail: juice-dev-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
|
|
|
Re: AW: AW: AW: Problems to setup Juice with Windows
by Berin Lautenbach
::
Rate this Message:
OK - I know what's causing it, but my knowledge of JNI is not good
enough for me to work out the best way to fix it. enabling -Xcheck:jni on the jvm call showed that the JEnv is being called by a non-java thread. By doing some tracing, I worked out that java_locking_callback is being called *after* junit has completed. My belief is that this is because the OpenSSL library shuts down on program exit. Because Java.exe is the program the DLL is hooked to, this is happening long after java has shut down the actual java environment. Assuming I'm correct, we need to do one of the following: 1. Have the provider shut down OpenSSL prior to everything finishing. 2. Have the program shut down OpenSSL prior to exitting - i.e. user responsibility (still need to implement the function to do this) 3. Have a check within the java_locking_callback that sees whether the JEnv is valid, and doesn't call it if it's not. Of the options, my favourite is 1 - is there some provider function that we can hook into here? Not guaranteed to work, there might be some locking calls that OpenSSL has to do on exit that we cannot pre-empt. Option 2 is horrible. Last case only. Option 3 is not the best, but will work if all else fails. We might be able to mix it with Option 1 - i.e. when the provider de-inits, call a function that unregisters the locking function in OpenSSL. Open to thoughts. Happy to do the implementation, but as I said, not enough of a JNI or provider expert to know which is the best option. Cheers, Berin Dittmann, Werner wrote: > Berin, > > thanks for the setup of the VC 6.0 project. After downloading > a Visual C++ Express environment (MS provides that free of > charge for everybody :-) ) plus the Platform SDK, thus installing > about 2GB of MS development environment I was able to build > the openSSL4Java.dll starting with your project files. > > Running the same test results in the same error. The Package > test terminated after 23 tests (I added 2 more tests for SecureRandom). > The result was a memory access violation. > > The I started a standalone test with the same result - but only after > all tests were done. This made me believe it has something to do with > process termination. Just as a simple test I added a System.exit(0) > call as the last line of the Package.java main method - and voila - no > more memory access error. > > As an additional test I forced one unit test to fail - also this > works as expected: it reports the failures and terminates without > memory access violation (after System.exit(0) was added. > > Because Java starts some threads internaly and tries to terminate > them in an orderly fashion - could it a threading problem? > > I just updated package.java and OpenSSLTestBlock.java to call > System.exit(0). IMHO we should try to drill down on the problem. > > Regards, > Werner > > >>-----Ursprüngliche Nachricht----- >>Von: Berin Lautenbach [mailto:berin@...] >>Gesendet: Mittwoch, 15. Februar 2006 11:30 >>An: juice-dev@... >>Betreff: Re: AW: AW: Problems to setup Juice with Windows >> >>The autogen problem was me Debian installing automake 1.4 by >>default(!) >> Once I had 1.9 everything was cool. >> >>I have imported a *very* basic debug build for VC 6.0 into the repo. >>There are some interesting complile time messages that I will >>look at, >>but I get 21 tests run successfully before I get a rather >>nasty memory >>access violation. I'll sort that one out in a few days as well :>. >> >>Cheers, >> Berin >> >>Dittmann, Werner wrote: >> >>>Berin, >>> >>>this project file is for the old juice native software. Pls >>>be informed that I introduced a new setup for Juice. >>> >>>The autoconf under Linux should simply work. Have a look >>>the the configure.ac and tha Makefile.am files, but running >>>./configure should work (if zou download the GZ file), otherwise >>>just run the autogen.sh script. This creates all necessary >>>files and runs ./configure. After "make" the shared lib >>>is in srcNew/.libs. >>> >>>Don't forget to set LD_LIBRARY_PATH correctly for the test >>>cases. >>> >>>Regards, >>>Werner >>> >>> >>> >>> >>>>-----Ursprüngliche Nachricht----- >>>>Von: Berin Lautenbach [mailto:berin@...] >>>>Gesendet: Dienstag, 14. Februar 2006 10:27 >>>>An: juice-dev@... >>>>Betreff: Re: AW: Problems to setup Juice with Windows >>>> >>>>Just started having a look. Is see there is already a >>>>project file for >>>>VC++ 6.0 in the old source directory. I'll set up something in the >>>>"standard" "Projects/..." folder structure to get it going. >>>> >>>>But first I'll get it running under Linux to see how it >>>>should work :>. >>>> Having an interesting time getting it to autoconf, but >> >>I'll work it >> >>>>out tomorrow night. >>>> >>>>Cheers, >>>> Berin >>>> >>>>Dittmann, Werner wrote: >>>> >>>> >>>> >>>>>Berin, >>>>> >>>>>sureI'm open to that. >>>>> >>>>>The whole native stuff is in plain C, just 5 modules >>>>>in C plus the headers. IMHO I don't use any stuff >>>>>that is Linux specific. >>>>> >>>>>The only prerequistite is the availabilty of the openSSL >>>>>headers and crypto lib. >>>>> >>>>>You can find the sources in incubator/juice/native/srcNew. >>>>> >>>>>If you have ides/questions just send a mail. >>>>> >>>>>Regards, >>>>>Werner >>>>> >>>>> >>>>> >>>>> >>>>>>-----Ursprüngliche Nachricht----- >>>>>>Von: Berin Lautenbach [mailto:berin@...] >>>>>>Gesendet: Dienstag, 14. Februar 2006 09:28 >>>>>>An: juice-dev@... >>>>>>Betreff: Re: Problems to setup Juice with Windows >>>>>> >>>>>>Having played with getting things running under Cygwin - I >>>> >>>>think I'd >>>> >>>> >>>>>>tend to agree with Scott. It adds some extra complications >>>> >>>>into the >>>> >>>> >>>>>>build/run process that could well trip you up. >>>>>> >>>>>>Is it possible to get the stuff to compile on VC++? Are you >>>>>>open for me >>>>>>to have a look to see if I can get it up and running? >>>>>> >>>>>>Cheers, >>>>>> Berin >>>>>> >>>>>>Scott Cantor wrote: >>>>>> >>>>>> >>>>>> >>>>>>>>- using cygwin I was able to setup the autoconf stuff, create a >>>>>>>>configure script, and compiled the native sources into a >>>>>> >>>>>>DLL. Before >>>>>> >>>>>> >>>>>> >>>>>>>>the compile was sucessful I copied the files "jni.h" and >>>>>> >>>>>>"jni_md.h" >>>>>> >>>>>> >>>>>> >>>>>>>>from the Java include directory to /usr/include of >> >>cygwin. Then I >> >>>>>>>>changed the "typedef __int64 jlong" to "typedef long >>>> >>>>long jint" to >>>> >>>> >>>>>>>>be compliant with gcc. >>>>>>> >>>>>>> >>>>>>>Is cygwin the way people would want to use this? I somehow >>>>>> >>>>>>doubt it. Most >>>>>> >>>>>> >>>>>> >>>>>>>people on Windows don't wish to pull in the cygwin DLLs, >>>>>> >>>>>>they want proper >>>>>> >>>>>> >>>>>> >>>>>>>Windows builds. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Any ideas? Any help is appreciated. >>>>>>> >>>>>>> >>>>>>>Regardless of the previous point, is there actual proof >>>>>> >>>>>>that the JVM can >>>>>> >>>>>> >>>>>> >>>>>>>load native code built with cygwin? Maybe it just works, >>>>>> >>>>>>but I'd try and >>>>>> >>>>>> >>>>>> >>>>>>>verify that independently before I went looking for root causes. >>>>>>> >>>>>>>-- Scott >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>------------------------------------------------------------ >>>> >>>>--------- >>>> >>>> >>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>------------------------------------------------------------ >>>> >>>>--------- >>>> >>>> >>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>------------------------------------------------------------ >> >>--------- >> >>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>>> >>>> >>>>------------------------------------------------------------ >> >>--------- >> >>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>> >>> >>> >>--------------------------------------------------------------------- >> >>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>For additional commands, e-mail: juice-dev-help@... >>> >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>For additional commands, e-mail: juice-dev-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: AW: AW: AW: Problems to setup Juice with Windows
by Berin Lautenbach
::
Rate this Message:
Been thinking about this more, so am going to display my complete Java
ignorance to ask some silly questions :>. Looking around on the web, I've found that the JNIEnv is thread unique, and it is important not to have one thread use a JNIEnv for another thread. However, the way the initialise works is it checks to see if OPenSSL is already initialised, if not set the global JNIEnv to be the JNIEnv of the current thread. Then it never enters again. However the thread locking function uses the global JNIEnv, which means it doesn't matter what thread calls it, it will always use that JNIEnv. That appears on the surface to be incorrect behaviour. Have I got this up wrong? Also, why do we use the Java thread locking system for OpenSSL? Is the normal OpenSSL system inadequate in the Java environment? Cheers, Berin Berin Lautenbach wrote: > OK - I know what's causing it, but my knowledge of JNI is not good > enough for me to work out the best way to fix it. > > enabling -Xcheck:jni on the jvm call showed that the JEnv is being > called by a non-java thread. > > By doing some tracing, I worked out that java_locking_callback is being > called *after* junit has completed. > > My belief is that this is because the OpenSSL library shuts down on > program exit. Because Java.exe is the program the DLL is hooked to, > this is happening long after java has shut down the actual java > environment. > > Assuming I'm correct, we need to do one of the following: > > 1. Have the provider shut down OpenSSL prior to everything finishing. > 2. Have the program shut down OpenSSL prior to exitting - i.e. user > responsibility (still need to implement the function to do this) > 3. Have a check within the java_locking_callback that sees whether the > JEnv is valid, and doesn't call it if it's not. > > Of the options, my favourite is 1 - is there some provider function that > we can hook into here? Not guaranteed to work, there might be some > locking calls that OpenSSL has to do on exit that we cannot pre-empt. > > Option 2 is horrible. Last case only. > > Option 3 is not the best, but will work if all else fails. We might be > able to mix it with Option 1 - i.e. when the provider de-inits, call a > function that unregisters the locking function in OpenSSL. > > Open to thoughts. Happy to do the implementation, but as I said, not > enough of a JNI or provider expert to know which is the best option. > > Cheers, > Berin > > > > Dittmann, Werner wrote: > >> Berin, >> >> thanks for the setup of the VC 6.0 project. After downloading >> a Visual C++ Express environment (MS provides that free of >> charge for everybody :-) ) plus the Platform SDK, thus installing >> about 2GB of MS development environment I was able to build >> the openSSL4Java.dll starting with your project files. >> >> Running the same test results in the same error. The Package >> test terminated after 23 tests (I added 2 more tests for SecureRandom). >> The result was a memory access violation. >> The I started a standalone test with the same result - but only after >> all tests were done. This made me believe it has something to do with >> process termination. Just as a simple test I added a System.exit(0) >> call as the last line of the Package.java main method - and voila - no >> more memory access error. >> >> As an additional test I forced one unit test to fail - also this >> works as expected: it reports the failures and terminates without >> memory access violation (after System.exit(0) was added. >> >> Because Java starts some threads internaly and tries to terminate >> them in an orderly fashion - could it a threading problem? >> >> I just updated package.java and OpenSSLTestBlock.java to call >> System.exit(0). IMHO we should try to drill down on the problem. >> >> Regards, >> Werner >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>> Mittwoch, 15. Februar 2006 11:30 >>> An: juice-dev@... >>> Betreff: Re: AW: AW: Problems to setup Juice with Windows >>> >>> The autogen problem was me Debian installing automake 1.4 by >>> default(!) Once I had 1.9 everything was cool. >>> >>> I have imported a *very* basic debug build for VC 6.0 into the repo. >>> There are some interesting complile time messages that I will look >>> at, but I get 21 tests run successfully before I get a rather nasty >>> memory access violation. I'll sort that one out in a few days as >>> well :>. >>> >>> Cheers, >>> Berin >>> >>> Dittmann, Werner wrote: >>> >>>> Berin, >>>> >>>> this project file is for the old juice native software. Pls >>>> be informed that I introduced a new setup for Juice. >>>> >>>> The autoconf under Linux should simply work. Have a look >>>> the the configure.ac and tha Makefile.am files, but running >>>> ./configure should work (if zou download the GZ file), otherwise >>>> just run the autogen.sh script. This creates all necessary >>>> files and runs ./configure. After "make" the shared lib >>>> is in srcNew/.libs. >>>> >>>> Don't forget to set LD_LIBRARY_PATH correctly for the test >>>> cases. >>>> >>>> Regards, >>>> Werner >>>> >>>> >>>> >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>> Dienstag, 14. Februar 2006 10:27 >>>>> An: juice-dev@... >>>>> Betreff: Re: AW: Problems to setup Juice with Windows >>>>> >>>>> Just started having a look. Is see there is already a project file >>>>> for VC++ 6.0 in the old source directory. I'll set up something in >>>>> the "standard" "Projects/..." folder structure to get it going. >>>>> >>>>> But first I'll get it running under Linux to see how it should work >>>>> :>. Having an interesting time getting it to autoconf, but >>> >>> >>> I'll work it >>> >>>>> out tomorrow night. >>>>> >>>>> Cheers, >>>>> Berin >>>>> >>>>> Dittmann, Werner wrote: >>>>> >>>>> >>>>> >>>>>> Berin, >>>>>> >>>>>> sureI'm open to that. >>>>>> The whole native stuff is in plain C, just 5 modules >>>>>> in C plus the headers. IMHO I don't use any stuff >>>>>> that is Linux specific. >>>>>> >>>>>> The only prerequistite is the availabilty of the openSSL >>>>>> headers and crypto lib. >>>>>> >>>>>> You can find the sources in incubator/juice/native/srcNew. >>>>>> >>>>>> If you have ides/questions just send a mail. >>>>>> >>>>>> Regards, >>>>>> Werner >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>> Dienstag, 14. Februar 2006 09:28 >>>>>>> An: juice-dev@... >>>>>>> Betreff: Re: Problems to setup Juice with Windows >>>>>>> >>>>>>> Having played with getting things running under Cygwin - I >>>>> >>>>> >>>>> think I'd >>>>> >>>>>>> tend to agree with Scott. It adds some extra complications >>>>> >>>>> >>>>> into the >>>>> >>>>>>> build/run process that could well trip you up. >>>>>>> >>>>>>> Is it possible to get the stuff to compile on VC++? Are you open >>>>>>> for me to have a look to see if I can get it up and running? >>>>>>> >>>>>>> Cheers, >>>>>>> Berin >>>>>>> >>>>>>> Scott Cantor wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> - using cygwin I was able to setup the autoconf stuff, create a >>>>>>>>> configure script, and compiled the native sources into a >>>>>>> >>>>>>> >>>>>>> DLL. Before >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> the compile was sucessful I copied the files "jni.h" and >>>>>>> >>>>>>> >>>>>>> "jni_md.h" >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> from the Java include directory to /usr/include of >>> >>> >>> cygwin. Then I >>> >>>>>>>>> changed the "typedef __int64 jlong" to "typedef long >>>>> >>>>> >>>>> long jint" to >>>>> >>>>> >>>>>>>>> be compliant with gcc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Is cygwin the way people would want to use this? I somehow >>>>>>> >>>>>>> >>>>>>> doubt it. Most >>>>>>> >>>>>>> >>>>>>> >>>>>>>> people on Windows don't wish to pull in the cygwin DLLs, >>>>>>> >>>>>>> >>>>>>> they want proper >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Windows builds. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Any ideas? Any help is appreciated. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regardless of the previous point, is there actual proof >>>>>>> >>>>>>> >>>>>>> that the JVM can >>>>>>> >>>>>>> >>>>>>> >>>>>>>> load native code built with cygwin? Maybe it just works, >>>>>>> >>>>>>> >>>>>>> but I'd try and >>>>>>> >>>>>>> >>>>>>> >>>>>>>> verify that independently before I went looking for root causes. >>>>>>>> >>>>>>>> -- Scott >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------ >>>>> >>>>> >>>>> --------- >>>>> >>>>> >>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------ >>>>> >>>>> >>>>> --------- >>>>> >>>>> >>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------ >>> >>> >>> --------- >>> >>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------ >>> >>> >>> --------- >>> >>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>> For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> >>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>> For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>> For additional commands, e-mail: juice-dev-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: juice-dev-unsubscribe@... >> For additional commands, e-mail: juice-dev-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: AW: AW: AW: Problems to setup Juice with Windows
by Bugzilla from werner.dittmann@t-online.de
::
Rate this Message:
Berin,
thanks for point out the JNIEnv and thread problem - I didn't catch that while reading the JNI docs. Well, The idea to use the Jave thread locking was driven to be fully interoperable with Java threading :-) ... I'm not sure if for example in Linux the pthreads work together with Java. Thus I thought it would be a goo idea to use Java's own thread locking - not I have a backfire. I'm going to think about the problem and see how it can be solved. Regards, Werner Berin Lautenbach wrote: > Been thinking about this more, so am going to display my complete Java > ignorance to ask some silly questions :>. > > Looking around on the web, I've found that the JNIEnv is thread unique, > and it is important not to have one thread use a JNIEnv for another thread. > > However, the way the initialise works is it checks to see if OPenSSL is > already initialised, if not set the global JNIEnv to be the JNIEnv of > the current thread. Then it never enters again. > > However the thread locking function uses the global JNIEnv, which means > it doesn't matter what thread calls it, it will always use that JNIEnv. > That appears on the surface to be incorrect behaviour. > > Have I got this up wrong? > > Also, why do we use the Java thread locking system for OpenSSL? Is the > normal OpenSSL system inadequate in the Java environment? > > Cheers, > Berin > > Berin Lautenbach wrote: > >> OK - I know what's causing it, but my knowledge of JNI is not good >> enough for me to work out the best way to fix it. >> >> enabling -Xcheck:jni on the jvm call showed that the JEnv is being >> called by a non-java thread. >> >> By doing some tracing, I worked out that java_locking_callback is >> being called *after* junit has completed. >> >> My belief is that this is because the OpenSSL library shuts down on >> program exit. Because Java.exe is the program the DLL is hooked to, >> this is happening long after java has shut down the actual java >> environment. >> >> Assuming I'm correct, we need to do one of the following: >> >> 1. Have the provider shut down OpenSSL prior to everything finishing. >> 2. Have the program shut down OpenSSL prior to exitting - i.e. user >> responsibility (still need to implement the function to do this) >> 3. Have a check within the java_locking_callback that sees whether >> the JEnv is valid, and doesn't call it if it's not. >> >> Of the options, my favourite is 1 - is there some provider function >> that we can hook into here? Not guaranteed to work, there might be >> some locking calls that OpenSSL has to do on exit that we cannot >> pre-empt. >> >> Option 2 is horrible. Last case only. >> >> Option 3 is not the best, but will work if all else fails. We might >> be able to mix it with Option 1 - i.e. when the provider de-inits, >> call a function that unregisters the locking function in OpenSSL. >> >> Open to thoughts. Happy to do the implementation, but as I said, not >> enough of a JNI or provider expert to know which is the best option. >> >> Cheers, >> Berin >> >> >> >> Dittmann, Werner wrote: >> >>> Berin, >>> >>> thanks for the setup of the VC 6.0 project. After downloading >>> a Visual C++ Express environment (MS provides that free of >>> charge for everybody :-) ) plus the Platform SDK, thus installing >>> about 2GB of MS development environment I was able to build >>> the openSSL4Java.dll starting with your project files. >>> >>> Running the same test results in the same error. The Package >>> test terminated after 23 tests (I added 2 more tests for SecureRandom). >>> The result was a memory access violation. >>> The I started a standalone test with the same result - but only after >>> all tests were done. This made me believe it has something to do with >>> process termination. Just as a simple test I added a System.exit(0) >>> call as the last line of the Package.java main method - and voila - no >>> more memory access error. >>> >>> As an additional test I forced one unit test to fail - also this >>> works as expected: it reports the failures and terminates without >>> memory access violation (after System.exit(0) was added. >>> >>> Because Java starts some threads internaly and tries to terminate >>> them in an orderly fashion - could it a threading problem? >>> >>> I just updated package.java and OpenSSLTestBlock.java to call >>> System.exit(0). IMHO we should try to drill down on the problem. >>> >>> Regards, >>> Werner >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>> Mittwoch, 15. Februar 2006 11:30 >>>> An: juice-dev@... >>>> Betreff: Re: AW: AW: Problems to setup Juice with Windows >>>> >>>> The autogen problem was me Debian installing automake 1.4 by >>>> default(!) Once I had 1.9 everything was cool. >>>> >>>> I have imported a *very* basic debug build for VC 6.0 into the repo. >>>> There are some interesting complile time messages that I will look >>>> at, but I get 21 tests run successfully before I get a rather nasty >>>> memory access violation. I'll sort that one out in a few days as >>>> well :>. >>>> >>>> Cheers, >>>> Berin >>>> >>>> Dittmann, Werner wrote: >>>> >>>>> Berin, >>>>> >>>>> this project file is for the old juice native software. Pls >>>>> be informed that I introduced a new setup for Juice. >>>>> >>>>> The autoconf under Linux should simply work. Have a look >>>>> the the configure.ac and tha Makefile.am files, but running >>>>> ./configure should work (if zou download the GZ file), otherwise >>>>> just run the autogen.sh script. This creates all necessary >>>>> files and runs ./configure. After "make" the shared lib >>>>> is in srcNew/.libs. >>>>> >>>>> Don't forget to set LD_LIBRARY_PATH correctly for the test >>>>> cases. >>>>> >>>>> Regards, >>>>> Werner >>>>> >>>>> >>>>> >>>>> >>>>>> -----Ursprüngliche Nachricht----- >>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>> Dienstag, 14. Februar 2006 10:27 >>>>>> An: juice-dev@... >>>>>> Betreff: Re: AW: Problems to setup Juice with Windows >>>>>> >>>>>> Just started having a look. Is see there is already a project >>>>>> file for VC++ 6.0 in the old source directory. I'll set up >>>>>> something in the "standard" "Projects/..." folder structure to get >>>>>> it going. >>>>>> >>>>>> But first I'll get it running under Linux to see how it should >>>>>> work :>. Having an interesting time getting it to autoconf, but >>>> >>>> >>>> >>>> I'll work it >>>> >>>>>> out tomorrow night. >>>>>> >>>>>> Cheers, >>>>>> Berin >>>>>> >>>>>> Dittmann, Werner wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Berin, >>>>>>> >>>>>>> sureI'm open to that. >>>>>>> The whole native stuff is in plain C, just 5 modules >>>>>>> in C plus the headers. IMHO I don't use any stuff >>>>>>> that is Linux specific. >>>>>>> >>>>>>> The only prerequistite is the availabilty of the openSSL >>>>>>> headers and crypto lib. >>>>>>> >>>>>>> You can find the sources in incubator/juice/native/srcNew. >>>>>>> >>>>>>> If you have ides/questions just send a mail. >>>>>>> >>>>>>> Regards, >>>>>>> Werner >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>> Dienstag, 14. Februar 2006 09:28 >>>>>>>> An: juice-dev@... >>>>>>>> Betreff: Re: Problems to setup Juice with Windows >>>>>>>> >>>>>>>> Having played with getting things running under Cygwin - I >>>>>> >>>>>> >>>>>> >>>>>> think I'd >>>>>> >>>>>>>> tend to agree with Scott. It adds some extra complications >>>>>> >>>>>> >>>>>> >>>>>> into the >>>>>> >>>>>>>> build/run process that could well trip you up. >>>>>>>> >>>>>>>> Is it possible to get the stuff to compile on VC++? Are you >>>>>>>> open for me to have a look to see if I can get it up and running? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Berin >>>>>>>> >>>>>>>> Scott Cantor wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> - using cygwin I was able to setup the autoconf stuff, create a >>>>>>>>>> configure script, and compiled the native sources into a >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> DLL. Before >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> the compile was sucessful I copied the files "jni.h" and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> "jni_md.h" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> from the Java include directory to /usr/include of >>>> >>>> >>>> >>>> cygwin. Then I >>>> >>>>>>>>>> changed the "typedef __int64 jlong" to "typedef long >>>>>> >>>>>> >>>>>> >>>>>> long jint" to >>>>>> >>>>>> >>>>>>>>>> be compliant with gcc. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Is cygwin the way people would want to use this? I somehow >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> doubt it. Most >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> people on Windows don't wish to pull in the cygwin DLLs, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> they want proper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Windows builds. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Any ideas? Any help is appreciated. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regardless of the previous point, is there actual proof >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> that the JVM can >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> load native code built with cygwin? Maybe it just works, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> but I'd try and >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> verify that independently before I went looking for root causes. >>>>>>>>> >>>>>>>>> -- Scott >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> --------- >>>>>> >>>>>> >>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> --------- >>>>>> >>>>>> >>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------ >>>> >>>> >>>> >>>> --------- >>>> >>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >>>> >>>> >>>> >>>> --------- >>>> >>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> >>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>> For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>> For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>> For additional commands, e-mail: juice-dev-help@... >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: juice-dev-unsubscribe@... >> For additional commands, e-mail: juice-dev-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
AW: Problems to setup Juice with Windows
by Bugzilla from werner.dittmann@t-online.de
::
Rate this Message:
Berin,
after looking into the problem I changed the thread locking to use pthreads on Linux and mutexes for Windows. Pls have a look into the modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing Windows maybe tomorrow. Regards, Werner Werner Dittmann wrote: > Berin, > > thanks for point out the JNIEnv and thread problem - I didn't catch that > while reading the JNI docs. > > Well, The idea to use the Jave thread locking was driven to be fully > interoperable with Java threading :-) ... I'm not sure if for example > in Linux the pthreads work together with Java. Thus I thought it would > be a goo idea to use Java's own thread locking - not I have a backfire. > > I'm going to think about the problem and see how it can be solved. > > Regards, > Werner > > > Berin Lautenbach wrote: > >>Been thinking about this more, so am going to display my complete Java >>ignorance to ask some silly questions :>. >> >>Looking around on the web, I've found that the JNIEnv is thread unique, >>and it is important not to have one thread use a JNIEnv for another thread. >> >>However, the way the initialise works is it checks to see if OPenSSL is >>already initialised, if not set the global JNIEnv to be the JNIEnv of >>the current thread. Then it never enters again. >> >>However the thread locking function uses the global JNIEnv, which means >>it doesn't matter what thread calls it, it will always use that JNIEnv. >> That appears on the surface to be incorrect behaviour. >> >>Have I got this up wrong? >> >>Also, why do we use the Java thread locking system for OpenSSL? Is the >>normal OpenSSL system inadequate in the Java environment? >> >>Cheers, >> Berin >> >>Berin Lautenbach wrote: >> >> >>>OK - I know what's causing it, but my knowledge of JNI is not good >>>enough for me to work out the best way to fix it. >>> >>>enabling -Xcheck:jni on the jvm call showed that the JEnv is being >>>called by a non-java thread. >>> >>>By doing some tracing, I worked out that java_locking_callback is >>>being called *after* junit has completed. >>> >>>My belief is that this is because the OpenSSL library shuts down on >>>program exit. Because Java.exe is the program the DLL is hooked to, >>>this is happening long after java has shut down the actual java >>>environment. >>> >>>Assuming I'm correct, we need to do one of the following: >>> >>>1. Have the provider shut down OpenSSL prior to everything finishing. >>>2. Have the program shut down OpenSSL prior to exitting - i.e. user >>>responsibility (still need to implement the function to do this) >>>3. Have a check within the java_locking_callback that sees whether >>>the JEnv is valid, and doesn't call it if it's not. >>> >>>Of the options, my favourite is 1 - is there some provider function >>>that we can hook into here? Not guaranteed to work, there might be >>>some locking calls that OpenSSL has to do on exit that we cannot >>>pre-empt. >>> >>>Option 2 is horrible. Last case only. >>> >>>Option 3 is not the best, but will work if all else fails. We might >>>be able to mix it with Option 1 - i.e. when the provider de-inits, >>>call a function that unregisters the locking function in OpenSSL. >>> >>>Open to thoughts. Happy to do the implementation, but as I said, not >>>enough of a JNI or provider expert to know which is the best option. >>> >>>Cheers, >>> Berin >>> >>> >>> >>>Dittmann, Werner wrote: >>> >>> >>>>Berin, >>>> >>>>thanks for the setup of the VC 6.0 project. After downloading >>>>a Visual C++ Express environment (MS provides that free of >>>>charge for everybody :-) ) plus the Platform SDK, thus installing >>>>about 2GB of MS development environment I was able to build >>>>the openSSL4Java.dll starting with your project files. >>>> >>>>Running the same test results in the same error. The Package >>>>test terminated after 23 tests (I added 2 more tests for SecureRandom). >>>>The result was a memory access violation. >>>>The I started a standalone test with the same result - but only after >>>>all tests were done. This made me believe it has something to do with >>>>process termination. Just as a simple test I added a System.exit(0) >>>>call as the last line of the Package.java main method - and voila - no >>>>more memory access error. >>>> >>>>As an additional test I forced one unit test to fail - also this >>>>works as expected: it reports the failures and terminates without >>>>memory access violation (after System.exit(0) was added. >>>> >>>>Because Java starts some threads internaly and tries to terminate >>>>them in an orderly fashion - could it a threading problem? >>>> >>>>I just updated package.java and OpenSSLTestBlock.java to call >>>>System.exit(0). IMHO we should try to drill down on the problem. >>>> >>>>Regards, >>>>Werner >>>> >>>> >>>> >>>>>-----Ursprüngliche Nachricht----- >>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>Mittwoch, 15. Februar 2006 11:30 >>>>>An: juice-dev@... >>>>>Betreff: Re: AW: AW: Problems to setup Juice with Windows >>>>> >>>>>The autogen problem was me Debian installing automake 1.4 by >>>>>default(!) Once I had 1.9 everything was cool. >>>>> >>>>>I have imported a *very* basic debug build for VC 6.0 into the repo. >>>>>There are some interesting complile time messages that I will look >>>>>at, but I get 21 tests run successfully before I get a rather nasty >>>>>memory access violation. I'll sort that one out in a few days as >>>>>well :>. >>>>> >>>>>Cheers, >>>>> Berin >>>>> >>>>>Dittmann, Werner wrote: >>>>> >>>>> >>>>>>Berin, >>>>>> >>>>>>this project file is for the old juice native software. Pls >>>>>>be informed that I introduced a new setup for Juice. >>>>>> >>>>>>The autoconf under Linux should simply work. Have a look >>>>>>the the configure.ac and tha Makefile.am files, but running >>>>>>./configure should work (if zou download the GZ file), otherwise >>>>>>just run the autogen.sh script. This creates all necessary >>>>>>files and runs ./configure. After "make" the shared lib >>>>>>is in srcNew/.libs. >>>>>> >>>>>>Don't forget to set LD_LIBRARY_PATH correctly for the test >>>>>>cases. >>>>>> >>>>>>Regards, >>>>>>Werner >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Ursprüngliche Nachricht----- >>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>Dienstag, 14. Februar 2006 10:27 >>>>>>>An: juice-dev@... >>>>>>>Betreff: Re: AW: Problems to setup Juice with Windows >>>>>>> >>>>>>>Just started having a look. Is see there is already a project >>>>>>>file for VC++ 6.0 in the old source directory. I'll set up >>>>>>>something in the "standard" "Projects/..." folder structure to get >>>>>>>it going. >>>>>>> >>>>>>>But first I'll get it running under Linux to see how it should >>>>>>>work :>. Having an interesting time getting it to autoconf, but >>>>> >>>>> >>>>> >>>>>I'll work it >>>>> >>>>> >>>>>>>out tomorrow night. >>>>>>> >>>>>>>Cheers, >>>>>>> Berin >>>>>>> >>>>>>>Dittmann, Werner wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Berin, >>>>>>>> >>>>>>>>sureI'm open to that. >>>>>>>>The whole native stuff is in plain C, just 5 modules >>>>>>>>in C plus the headers. IMHO I don't use any stuff >>>>>>>>that is Linux specific. >>>>>>>> >>>>>>>>The only prerequistite is the availabilty of the openSSL >>>>>>>>headers and crypto lib. >>>>>>>> >>>>>>>>You can find the sources in incubator/juice/native/srcNew. >>>>>>>> >>>>>>>>If you have ides/questions just send a mail. >>>>>>>> >>>>>>>>Regards, >>>>>>>>Werner >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>-----Ursprüngliche Nachricht----- >>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>>Dienstag, 14. Februar 2006 09:28 >>>>>>>>>An: juice-dev@... >>>>>>>>>Betreff: Re: Problems to setup Juice with Windows >>>>>>>>> >>>>>>>>>Having played with getting things running under Cygwin - I >>>>>>> >>>>>>> >>>>>>> >>>>>>>think I'd >>>>>>> >>>>>>> >>>>>>>>>tend to agree with Scott. It adds some extra complications >>>>>>> >>>>>>> >>>>>>> >>>>>>>into the >>>>>>> >>>>>>> >>>>>>>>>build/run process that could well trip you up. >>>>>>>>> >>>>>>>>>Is it possible to get the stuff to compile on VC++? Are you >>>>>>>>>open for me to have a look to see if I can get it up and running? >>>>>>>>> >>>>>>>>>Cheers, >>>>>>>>> Berin >>>>>>>>> >>>>>>>>>Scott Cantor wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>- using cygwin I was able to setup the autoconf stuff, create a >>>>>>>>>>>configure script, and compiled the native sources into a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>DLL. Before >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>the compile was sucessful I copied the files "jni.h" and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>"jni_md.h" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>from the Java include directory to /usr/include of >>>>> >>>>> >>>>> >>>>>cygwin. Then I >>>>> >>>>> >>>>>>>>>>>changed the "typedef __int64 jlong" to "typedef long >>>>>>> >>>>>>> >>>>>>> >>>>>>>long jint" to >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>be compliant with gcc. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Is cygwin the way people would want to use this? I somehow >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>doubt it. Most >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>people on Windows don't wish to pull in the cygwin DLLs, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>they want proper >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Windows builds. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Any ideas? Any help is appreciated. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Regardless of the previous point, is there actual proof >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>that the JVM can >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>load native code built with cygwin? Maybe it just works, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>but I'd try and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>verify that independently before I went looking for root causes. >>>>>>>>>> >>>>>>>>>>-- Scott >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>>--------- >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>>--------- >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>>--------- >>>>> >>>>> >>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>>--------- >>>>> >>>>> >>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>--------------------------------------------------------------------- >>>>> >>>>> >>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>>> >>>>> >>>>>--------------------------------------------------------------------- >>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>> >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>For additional commands, e-mail: juice-dev-help@... >>> >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>For additional commands, e-mail: juice-dev-help@... >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: AW: Problems to setup Juice with Windows
by Berin Lautenbach
::
Rate this Message:
Werner,
1st question - am I able to get a copy of the signing keystore for the JAR file? I've done some minor mods, but I cannot test. I took your changes, cleaned up a couple of minor warnings under VC 6.0 and compiled into a new DLL. Of course I then got JNI errors because my JAR was still calling the old methods. I then went and updated the InitializeOpenSSL.java file. Then everything broke completely because my JAR is not signed :>. So I've checked in the slightly cleaned code, and a new version of the project file that includes all the files for a debug build. If I am allowed to get something that allows me to sign the jar that would be fantastic! NOTE - I've *not* checked in my changes to the java code. Cheers, Berin Werner Dittmann wrote: > Berin, > > after looking into the problem I changed the thread locking to use > pthreads on Linux and mutexes for Windows. Pls have a look into the > modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing > Windows maybe tomorrow. > > Regards, > Werner > > Werner Dittmann wrote: > >>Berin, >> >>thanks for point out the JNIEnv and thread problem - I didn't catch that >>while reading the JNI docs. >> >>Well, The idea to use the Jave thread locking was driven to be fully >>interoperable with Java threading :-) ... I'm not sure if for example >>in Linux the pthreads work together with Java. Thus I thought it would >>be a goo idea to use Java's own thread locking - not I have a backfire. >> >>I'm going to think about the problem and see how it can be solved. >> >>Regards, >>Werner >> >> >>Berin Lautenbach wrote: >> >> >>>Been thinking about this more, so am going to display my complete Java >>>ignorance to ask some silly questions :>. >>> >>>Looking around on the web, I've found that the JNIEnv is thread unique, >>>and it is important not to have one thread use a JNIEnv for another thread. >>> >>>However, the way the initialise works is it checks to see if OPenSSL is >>>already initialised, if not set the global JNIEnv to be the JNIEnv of >>>the current thread. Then it never enters again. >>> >>>However the thread locking function uses the global JNIEnv, which means >>>it doesn't matter what thread calls it, it will always use that JNIEnv. >>>That appears on the surface to be incorrect behaviour. >>> >>>Have I got this up wrong? >>> >>>Also, why do we use the Java thread locking system for OpenSSL? Is the >>>normal OpenSSL system inadequate in the Java environment? >>> >>>Cheers, >>> Berin >>> >>>Berin Lautenbach wrote: >>> >>> >>> >>>>OK - I know what's causing it, but my knowledge of JNI is not good >>>>enough for me to work out the best way to fix it. >>>> >>>>enabling -Xcheck:jni on the jvm call showed that the JEnv is being >>>>called by a non-java thread. >>>> >>>>By doing some tracing, I worked out that java_locking_callback is >>>>being called *after* junit has completed. >>>> >>>>My belief is that this is because the OpenSSL library shuts down on >>>>program exit. Because Java.exe is the program the DLL is hooked to, >>>>this is happening long after java has shut down the actual java >>>>environment. >>>> >>>>Assuming I'm correct, we need to do one of the following: >>>> >>>>1. Have the provider shut down OpenSSL prior to everything finishing. >>>>2. Have the program shut down OpenSSL prior to exitting - i.e. user >>>>responsibility (still need to implement the function to do this) >>>>3. Have a check within the java_locking_callback that sees whether >>>>the JEnv is valid, and doesn't call it if it's not. >>>> >>>>Of the options, my favourite is 1 - is there some provider function >>>>that we can hook into here? Not guaranteed to work, there might be >>>>some locking calls that OpenSSL has to do on exit that we cannot >>>>pre-empt. >>>> >>>>Option 2 is horrible. Last case only. >>>> >>>>Option 3 is not the best, but will work if all else fails. We might >>>>be able to mix it with Option 1 - i.e. when the provider de-inits, >>>>call a function that unregisters the locking function in OpenSSL. >>>> >>>>Open to thoughts. Happy to do the implementation, but as I said, not >>>>enough of a JNI or provider expert to know which is the best option. >>>> >>>>Cheers, >>>> Berin >>>> >>>> >>>> >>>>Dittmann, Werner wrote: >>>> >>>> >>>> >>>>>Berin, >>>>> >>>>>thanks for the setup of the VC 6.0 project. After downloading >>>>>a Visual C++ Express environment (MS provides that free of >>>>>charge for everybody :-) ) plus the Platform SDK, thus installing >>>>>about 2GB of MS development environment I was able to build >>>>>the openSSL4Java.dll starting with your project files. >>>>> >>>>>Running the same test results in the same error. The Package >>>>>test terminated after 23 tests (I added 2 more tests for SecureRandom). >>>>>The result was a memory access violation. >>>>>The I started a standalone test with the same result - but only after >>>>>all tests were done. This made me believe it has something to do with >>>>>process termination. Just as a simple test I added a System.exit(0) >>>>>call as the last line of the Package.java main method - and voila - no >>>>>more memory access error. >>>>> >>>>>As an additional test I forced one unit test to fail - also this >>>>>works as expected: it reports the failures and terminates without >>>>>memory access violation (after System.exit(0) was added. >>>>> >>>>>Because Java starts some threads internaly and tries to terminate >>>>>them in an orderly fashion - could it a threading problem? >>>>> >>>>>I just updated package.java and OpenSSLTestBlock.java to call >>>>>System.exit(0). IMHO we should try to drill down on the problem. >>>>> >>>>>Regards, >>>>>Werner >>>>> >>>>> >>>>> >>>>> >>>>>>-----Ursprüngliche Nachricht----- >>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>Mittwoch, 15. Februar 2006 11:30 >>>>>>An: juice-dev@... >>>>>>Betreff: Re: AW: AW: Problems to setup Juice with Windows >>>>>> >>>>>>The autogen problem was me Debian installing automake 1.4 by >>>>>>default(!) Once I had 1.9 everything was cool. >>>>>> >>>>>>I have imported a *very* basic debug build for VC 6.0 into the repo. >>>>>>There are some interesting complile time messages that I will look >>>>>>at, but I get 21 tests run successfully before I get a rather nasty >>>>>>memory access violation. I'll sort that one out in a few days as >>>>>>well :>. >>>>>> >>>>>>Cheers, >>>>>> Berin >>>>>> >>>>>>Dittmann, Werner wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Berin, >>>>>>> >>>>>>>this project file is for the old juice native software. Pls >>>>>>>be informed that I introduced a new setup for Juice. >>>>>>> >>>>>>>The autoconf under Linux should simply work. Have a look >>>>>>>the the configure.ac and tha Makefile.am files, but running >>>>>>>./configure should work (if zou download the GZ file), otherwise >>>>>>>just run the autogen.sh script. This creates all necessary >>>>>>>files and runs ./configure. After "make" the shared lib >>>>>>>is in srcNew/.libs. >>>>>>> >>>>>>>Don't forget to set LD_LIBRARY_PATH correctly for the test >>>>>>>cases. >>>>>>> >>>>>>>Regards, >>>>>>>Werner >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Ursprüngliche Nachricht----- >>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>Dienstag, 14. Februar 2006 10:27 >>>>>>>>An: juice-dev@... >>>>>>>>Betreff: Re: AW: Problems to setup Juice with Windows >>>>>>>> >>>>>>>>Just started having a look. Is see there is already a project >>>>>>>>file for VC++ 6.0 in the old source directory. I'll set up >>>>>>>>something in the "standard" "Projects/..." folder structure to get >>>>>>>>it going. >>>>>>>> >>>>>>>>But first I'll get it running under Linux to see how it should >>>>>>>>work :>. Having an interesting time getting it to autoconf, but >>>>>> >>>>>> >>>>>> >>>>>>I'll work it >>>>>> >>>>>> >>>>>> >>>>>>>>out tomorrow night. >>>>>>>> >>>>>>>>Cheers, >>>>>>>> Berin >>>>>>>> >>>>>>>>Dittmann, Werner wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Berin, >>>>>>>>> >>>>>>>>>sureI'm open to that. >>>>>>>>>The whole native stuff is in plain C, just 5 modules >>>>>>>>>in C plus the headers. IMHO I don't use any stuff >>>>>>>>>that is Linux specific. >>>>>>>>> >>>>>>>>>The only prerequistite is the availabilty of the openSSL >>>>>>>>>headers and crypto lib. >>>>>>>>> >>>>>>>>>You can find the sources in incubator/juice/native/srcNew. >>>>>>>>> >>>>>>>>>If you have ides/questions just send a mail. >>>>>>>>> >>>>>>>>>Regards, >>>>>>>>>Werner >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>-----Ursprüngliche Nachricht----- >>>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>>>Dienstag, 14. Februar 2006 09:28 >>>>>>>>>>An: juice-dev@... >>>>>>>>>>Betreff: Re: Problems to setup Juice with Windows >>>>>>>>>> >>>>>>>>>>Having played with getting things running under Cygwin - I >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>think I'd >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>tend to agree with Scott. It adds some extra complications >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>into the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>build/run process that could well trip you up. >>>>>>>>>> >>>>>>>>>>Is it possible to get the stuff to compile on VC++? Are you >>>>>>>>>>open for me to have a look to see if I can get it up and running? >>>>>>>>>> >>>>>>>>>>Cheers, >>>>>>>>>> Berin >>>>>>>>>> >>>>>>>>>>Scott Cantor wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>- using cygwin I was able to setup the autoconf stuff, create a >>>>>>>>>>>>configure script, and compiled the native sources into a >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>DLL. Before >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>the compile was sucessful I copied the files "jni.h" and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>"jni_md.h" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>from the Java include directory to /usr/include of >>>>>> >>>>>> >>>>>> >>>>>>cygwin. Then I >>>>>> >>>>>> >>>>>> >>>>>>>>>>>>changed the "typedef __int64 jlong" to "typedef long >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>long jint" to >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>be compliant with gcc. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Is cygwin the way people would want to use this? I somehow >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>doubt it. Most >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>people on Windows don't wish to pull in the cygwin DLLs, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>they want proper >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Windows builds. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>Any ideas? Any help is appreciated. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Regardless of the previous point, is there actual proof >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>that the JVM can >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>load native code built with cygwin? Maybe it just works, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>but I'd try and >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>verify that independently before I went looking for root causes. >>>>>>>>>>> >>>>>>>>>>>-- Scott >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>--------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>--------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>>--------- >>>>>> >>>>>> >>>>>> >>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>>--------- >>>>>> >>>>>> >>>>>> >>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>--------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>> >>>>> >>>>>--------------------------------------------------------------------- >>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>>> >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>For additional commands, e-mail: juice-dev-help@... >>> >>> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>For additional commands, e-mail: juice-dev-help@... >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: AW: Problems to setup Juice with Windows
by Bugzilla from werner.dittmann@t-online.de
::
Rate this Message:
Berin,
usually I also update a signed jar into JuiCE's dist directory. Regards, Werner Berin Lautenbach wrote: > Werner, > > 1st question - am I able to get a copy of the signing keystore for the > JAR file? I've done some minor mods, but I cannot test. > > I took your changes, cleaned up a couple of minor warnings under VC 6.0 > and compiled into a new DLL. Of course I then got JNI errors because my > JAR was still calling the old methods. > > I then went and updated the InitializeOpenSSL.java file. Then > everything broke completely because my JAR is not signed :>. > > So I've checked in the slightly cleaned code, and a new version of the > project file that includes all the files for a debug build. If I am > allowed to get something that allows me to sign the jar that would be > fantastic! > > NOTE - I've *not* checked in my changes to the java code. > > Cheers, > Berin > > Werner Dittmann wrote: > >> Berin, >> >> after looking into the problem I changed the thread locking to use >> pthreads on Linux and mutexes for Windows. Pls have a look into the >> modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing >> Windows maybe tomorrow. >> >> Regards, >> Werner >> >> Werner Dittmann wrote: >> >>> Berin, >>> >>> thanks for point out the JNIEnv and thread problem - I didn't catch that >>> while reading the JNI docs. >>> >>> Well, The idea to use the Jave thread locking was driven to be fully >>> interoperable with Java threading :-) ... I'm not sure if for example >>> in Linux the pthreads work together with Java. Thus I thought it would >>> be a goo idea to use Java's own thread locking - not I have a backfire. >>> >>> I'm going to think about the problem and see how it can be solved. >>> >>> Regards, >>> Werner >>> >>> >>> Berin Lautenbach wrote: >>> >>> >>>> Been thinking about this more, so am going to display my complete Java >>>> ignorance to ask some silly questions :>. >>>> >>>> Looking around on the web, I've found that the JNIEnv is thread unique, >>>> and it is important not to have one thread use a JNIEnv for another >>>> thread. >>>> >>>> However, the way the initialise works is it checks to see if OPenSSL is >>>> already initialised, if not set the global JNIEnv to be the JNIEnv of >>>> the current thread. Then it never enters again. >>>> >>>> However the thread locking function uses the global JNIEnv, which means >>>> it doesn't matter what thread calls it, it will always use that JNIEnv. >>>> That appears on the surface to be incorrect behaviour. >>>> >>>> Have I got this up wrong? >>>> >>>> Also, why do we use the Java thread locking system for OpenSSL? Is the >>>> normal OpenSSL system inadequate in the Java environment? >>>> >>>> Cheers, >>>> Berin >>>> >>>> Berin Lautenbach wrote: >>>> >>>> >>>> >>>>> OK - I know what's causing it, but my knowledge of JNI is not good >>>>> enough for me to work out the best way to fix it. >>>>> >>>>> enabling -Xcheck:jni on the jvm call showed that the JEnv is being >>>>> called by a non-java thread. >>>>> >>>>> By doing some tracing, I worked out that java_locking_callback is >>>>> being called *after* junit has completed. >>>>> >>>>> My belief is that this is because the OpenSSL library shuts down on >>>>> program exit. Because Java.exe is the program the DLL is hooked to, >>>>> this is happening long after java has shut down the actual java >>>>> environment. >>>>> >>>>> Assuming I'm correct, we need to do one of the following: >>>>> >>>>> 1. Have the provider shut down OpenSSL prior to everything finishing. >>>>> 2. Have the program shut down OpenSSL prior to exitting - i.e. user >>>>> responsibility (still need to implement the function to do this) >>>>> 3. Have a check within the java_locking_callback that sees whether >>>>> the JEnv is valid, and doesn't call it if it's not. >>>>> >>>>> Of the options, my favourite is 1 - is there some provider function >>>>> that we can hook into here? Not guaranteed to work, there might be >>>>> some locking calls that OpenSSL has to do on exit that we cannot >>>>> pre-empt. >>>>> >>>>> Option 2 is horrible. Last case only. >>>>> >>>>> Option 3 is not the best, but will work if all else fails. We might >>>>> be able to mix it with Option 1 - i.e. when the provider de-inits, >>>>> call a function that unregisters the locking function in OpenSSL. >>>>> >>>>> Open to thoughts. Happy to do the implementation, but as I said, not >>>>> enough of a JNI or provider expert to know which is the best option. >>>>> >>>>> Cheers, >>>>> Berin >>>>> >>>>> >>>>> >>>>> Dittmann, Werner wrote: >>>>> >>>>> >>>>> >>>>>> Berin, >>>>>> >>>>>> thanks for the setup of the VC 6.0 project. After downloading >>>>>> a Visual C++ Express environment (MS provides that free of >>>>>> charge for everybody :-) ) plus the Platform SDK, thus installing >>>>>> about 2GB of MS development environment I was able to build >>>>>> the openSSL4Java.dll starting with your project files. >>>>>> >>>>>> Running the same test results in the same error. The Package >>>>>> test terminated after 23 tests (I added 2 more tests for >>>>>> SecureRandom). >>>>>> The result was a memory access violation. >>>>>> The I started a standalone test with the same result - but only after >>>>>> all tests were done. This made me believe it has something to do with >>>>>> process termination. Just as a simple test I added a System.exit(0) >>>>>> call as the last line of the Package.java main method - and voila >>>>>> - no >>>>>> more memory access error. >>>>>> >>>>>> As an additional test I forced one unit test to fail - also this >>>>>> works as expected: it reports the failures and terminates without >>>>>> memory access violation (after System.exit(0) was added. >>>>>> >>>>>> Because Java starts some threads internaly and tries to terminate >>>>>> them in an orderly fashion - could it a threading problem? >>>>>> >>>>>> I just updated package.java and OpenSSLTestBlock.java to call >>>>>> System.exit(0). IMHO we should try to drill down on the problem. >>>>>> >>>>>> Regards, >>>>>> Werner >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Ursprüngliche Nachricht----- >>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>> Mittwoch, 15. Februar 2006 11:30 >>>>>>> An: juice-dev@... >>>>>>> Betreff: Re: AW: AW: Problems to setup Juice with Windows >>>>>>> >>>>>>> The autogen problem was me Debian installing automake 1.4 by >>>>>>> default(!) Once I had 1.9 everything was cool. >>>>>>> >>>>>>> I have imported a *very* basic debug build for VC 6.0 into the repo. >>>>>>> There are some interesting complile time messages that I will look >>>>>>> at, but I get 21 tests run successfully before I get a rather nasty >>>>>>> memory access violation. I'll sort that one out in a few days as >>>>>>> well :>. >>>>>>> >>>>>>> Cheers, >>>>>>> Berin >>>>>>> >>>>>>> Dittmann, Werner wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Berin, >>>>>>>> >>>>>>>> this project file is for the old juice native software. Pls >>>>>>>> be informed that I introduced a new setup for Juice. >>>>>>>> >>>>>>>> The autoconf under Linux should simply work. Have a look >>>>>>>> the the configure.ac and tha Makefile.am files, but running >>>>>>>> ./configure should work (if zou download the GZ file), otherwise >>>>>>>> just run the autogen.sh script. This creates all necessary >>>>>>>> files and runs ./configure. After "make" the shared lib >>>>>>>> is in srcNew/.libs. >>>>>>>> >>>>>>>> Don't forget to set LD_LIBRARY_PATH correctly for the test >>>>>>>> cases. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Werner >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>> Dienstag, 14. Februar 2006 10:27 >>>>>>>>> An: juice-dev@... >>>>>>>>> Betreff: Re: AW: Problems to setup Juice with Windows >>>>>>>>> >>>>>>>>> Just started having a look. Is see there is already a project >>>>>>>>> file for VC++ 6.0 in the old source directory. I'll set up >>>>>>>>> something in the "standard" "Projects/..." folder structure to get >>>>>>>>> it going. >>>>>>>>> >>>>>>>>> But first I'll get it running under Linux to see how it should >>>>>>>>> work :>. Having an interesting time getting it to autoconf, but >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'll work it >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> out tomorrow night. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Berin >>>>>>>>> >>>>>>>>> Dittmann, Werner wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Berin, >>>>>>>>>> >>>>>>>>>> sureI'm open to that. >>>>>>>>>> The whole native stuff is in plain C, just 5 modules >>>>>>>>>> in C plus the headers. IMHO I don't use any stuff >>>>>>>>>> that is Linux specific. >>>>>>>>>> >>>>>>>>>> The only prerequistite is the availabilty of the openSSL >>>>>>>>>> headers and crypto lib. >>>>>>>>>> >>>>>>>>>> You can find the sources in incubator/juice/native/srcNew. >>>>>>>>>> >>>>>>>>>> If you have ides/questions just send a mail. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Werner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>>>> Dienstag, 14. Februar 2006 09:28 >>>>>>>>>>> An: juice-dev@... >>>>>>>>>>> Betreff: Re: Problems to setup Juice with Windows >>>>>>>>>>> >>>>>>>>>>> Having played with getting things running under Cygwin - I >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> think I'd >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> tend to agree with Scott. It adds some extra complications >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> into the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> build/run process that could well trip you up. >>>>>>>>>>> >>>>>>>>>>> Is it possible to get the stuff to compile on VC++? Are you >>>>>>>>>>> open for me to have a look to see if I can get it up and >>>>>>>>>>> running? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Berin >>>>>>>>>>> >>>>>>>>>>> Scott Cantor wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> - using cygwin I was able to setup the autoconf stuff, >>>>>>>>>>>>> create a >>>>>>>>>>>>> configure script, and compiled the native sources into a >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> DLL. Before >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> the compile was sucessful I copied the files "jni.h" and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> "jni_md.h" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> from the Java include directory to /usr/include of >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> cygwin. Then I >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>>>> changed the "typedef __int64 jlong" to "typedef long >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> long jint" to >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>> be compliant with gcc. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Is cygwin the way people would want to use this? I somehow >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> doubt it. Most >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> people on Windows don't wish to pull in the cygwin DLLs, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> they want proper >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Windows builds. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Any ideas? Any help is appreciated. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regardless of the previous point, is there actual proof >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> that the JVM can >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> load native code built with cygwin? Maybe it just works, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> but I'd try and >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> verify that independently before I went looking for root >>>>>>>>>>>> causes. >>>>>>>>>>>> >>>>>>>>>>>> -- Scott >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> --------- >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>> For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>> For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>> For additional commands, e-mail: juice-dev-help@... >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: juice-dev-unsubscribe@... >> For additional commands, e-mail: juice-dev-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: AW: Problems to setup Juice with Windows
by Berin Lautenbach
::
Rate this Message:
Used what you sent me and then updated the jar files - it works
beautifully now under Windows for a VC 6 debug build. I'll also add the files for release, VC 7 and VC 8 over the next couple of days. Nice! Cheers, Berin Werner Dittmann wrote: > Berin, > > usually I also update a signed jar into JuiCE's dist directory. > > Regards, > Werner > > Berin Lautenbach wrote: > >>Werner, >> >>1st question - am I able to get a copy of the signing keystore for the >>JAR file? I've done some minor mods, but I cannot test. >> >>I took your changes, cleaned up a couple of minor warnings under VC 6.0 >>and compiled into a new DLL. Of course I then got JNI errors because my >>JAR was still calling the old methods. >> >>I then went and updated the InitializeOpenSSL.java file. Then >>everything broke completely because my JAR is not signed :>. >> >>So I've checked in the slightly cleaned code, and a new version of the >>project file that includes all the files for a debug build. If I am >>allowed to get something that allows me to sign the jar that would be >>fantastic! >> >>NOTE - I've *not* checked in my changes to the java code. >> >>Cheers, >> Berin >> >>Werner Dittmann wrote: >> >> >>>Berin, >>> >>>after looking into the problem I changed the thread locking to use >>>pthreads on Linux and mutexes for Windows. Pls have a look into the >>>modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing >>>Windows maybe tomorrow. >>> >>>Regards, >>>Werner >>> >>>Werner Dittmann wrote: >>> >>> >>>>Berin, >>>> >>>>thanks for point out the JNIEnv and thread problem - I didn't catch that >>>>while reading the JNI docs. >>>> >>>>Well, The idea to use the Jave thread locking was driven to be fully >>>>interoperable with Java threading :-) ... I'm not sure if for example >>>>in Linux the pthreads work together with Java. Thus I thought it would >>>>be a goo idea to use Java's own thread locking - not I have a backfire. >>>> >>>>I'm going to think about the problem and see how it can be solved. >>>> >>>>Regards, >>>>Werner >>>> >>>> >>>>Berin Lautenbach wrote: >>>> >>>> >>>> >>>>>Been thinking about this more, so am going to display my complete Java >>>>>ignorance to ask some silly questions :>. >>>>> >>>>>Looking around on the web, I've found that the JNIEnv is thread unique, >>>>>and it is important not to have one thread use a JNIEnv for another >>>>>thread. >>>>> >>>>>However, the way the initialise works is it checks to see if OPenSSL is >>>>>already initialised, if not set the global JNIEnv to be the JNIEnv of >>>>>the current thread. Then it never enters again. >>>>> >>>>>However the thread locking function uses the global JNIEnv, which means >>>>>it doesn't matter what thread calls it, it will always use that JNIEnv. >>>>>That appears on the surface to be incorrect behaviour. >>>>> >>>>>Have I got this up wrong? >>>>> >>>>>Also, why do we use the Java thread locking system for OpenSSL? Is the >>>>>normal OpenSSL system inadequate in the Java environment? >>>>> >>>>>Cheers, >>>>> Berin >>>>> >>>>>Berin Lautenbach wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>OK - I know what's causing it, but my knowledge of JNI is not good >>>>>>enough for me to work out the best way to fix it. >>>>>> >>>>>>enabling -Xcheck:jni on the jvm call showed that the JEnv is being >>>>>>called by a non-java thread. >>>>>> >>>>>>By doing some tracing, I worked out that java_locking_callback is >>>>>>being called *after* junit has completed. >>>>>> >>>>>>My belief is that this is because the OpenSSL library shuts down on >>>>>>program exit. Because Java.exe is the program the DLL is hooked to, >>>>>>this is happening long after java has shut down the actual java >>>>>>environment. >>>>>> >>>>>>Assuming I'm correct, we need to do one of the following: >>>>>> >>>>>>1. Have the provider shut down OpenSSL prior to everything finishing. >>>>>>2. Have the program shut down OpenSSL prior to exitting - i.e. user >>>>>>responsibility (still need to implement the function to do this) >>>>>>3. Have a check within the java_locking_callback that sees whether >>>>>>the JEnv is valid, and doesn't call it if it's not. >>>>>> >>>>>>Of the options, my favourite is 1 - is there some provider function >>>>>>that we can hook into here? Not guaranteed to work, there might be >>>>>>some locking calls that OpenSSL has to do on exit that we cannot >>>>>>pre-empt. >>>>>> >>>>>>Option 2 is horrible. Last case only. >>>>>> >>>>>>Option 3 is not the best, but will work if all else fails. We might >>>>>>be able to mix it with Option 1 - i.e. when the provider de-inits, >>>>>>call a function that unregisters the locking function in OpenSSL. >>>>>> >>>>>>Open to thoughts. Happy to do the implementation, but as I said, not >>>>>>enough of a JNI or provider expert to know which is the best option. >>>>>> >>>>>>Cheers, >>>>>> Berin >>>>>> >>>>>> >>>>>> >>>>>>Dittmann, Werner wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Berin, >>>>>>> >>>>>>>thanks for the setup of the VC 6.0 project. After downloading >>>>>>>a Visual C++ Express environment (MS provides that free of >>>>>>>charge for everybody :-) ) plus the Platform SDK, thus installing >>>>>>>about 2GB of MS development environment I was able to build >>>>>>>the openSSL4Java.dll starting with your project files. >>>>>>> >>>>>>>Running the same test results in the same error. The Package >>>>>>>test terminated after 23 tests (I added 2 more tests for >>>>>>>SecureRandom). >>>>>>>The result was a memory access violation. >>>>>>>The I started a standalone test with the same result - but only after >>>>>>>all tests were done. This made me believe it has something to do with >>>>>>>process termination. Just as a simple test I added a System.exit(0) >>>>>>>call as the last line of the Package.java main method - and voila >>>>>>>- no >>>>>>>more memory access error. >>>>>>> >>>>>>>As an additional test I forced one unit test to fail - also this >>>>>>>works as expected: it reports the failures and terminates without >>>>>>>memory access violation (after System.exit(0) was added. >>>>>>> >>>>>>>Because Java starts some threads internaly and tries to terminate >>>>>>>them in an orderly fashion - could it a threading problem? >>>>>>> >>>>>>>I just updated package.java and OpenSSLTestBlock.java to call >>>>>>>System.exit(0). IMHO we should try to drill down on the problem. >>>>>>> >>>>>>>Regards, >>>>>>>Werner >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Ursprüngliche Nachricht----- >>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>Mittwoch, 15. Februar 2006 11:30 >>>>>>>>An: juice-dev@... >>>>>>>>Betreff: Re: AW: AW: Problems to setup Juice with Windows >>>>>>>> >>>>>>>>The autogen problem was me Debian installing automake 1.4 by >>>>>>>>default(!) Once I had 1.9 everything was cool. >>>>>>>> >>>>>>>>I have imported a *very* basic debug build for VC 6.0 into the repo. >>>>>>>>There are some interesting complile time messages that I will look >>>>>>>>at, but I get 21 tests run successfully before I get a rather nasty >>>>>>>>memory access violation. I'll sort that one out in a few days as >>>>>>>>well :>. >>>>>>>> >>>>>>>>Cheers, >>>>>>>> Berin >>>>>>>> >>>>>>>>Dittmann, Werner wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Berin, >>>>>>>>> >>>>>>>>>this project file is for the old juice native software. Pls >>>>>>>>>be informed that I introduced a new setup for Juice. >>>>>>>>> >>>>>>>>>The autoconf under Linux should simply work. Have a look >>>>>>>>>the the configure.ac and tha Makefile.am files, but running >>>>>>>>>./configure should work (if zou download the GZ file), otherwise >>>>>>>>>just run the autogen.sh script. This creates all necessary >>>>>>>>>files and runs ./configure. After "make" the shared lib >>>>>>>>>is in srcNew/.libs. >>>>>>>>> >>>>>>>>>Don't forget to set LD_LIBRARY_PATH correctly for the test >>>>>>>>>cases. >>>>>>>>> >>>>>>>>>Regards, >>>>>>>>>Werner >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>-----Ursprüngliche Nachricht----- >>>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>>>Dienstag, 14. Februar 2006 10:27 >>>>>>>>>>An: juice-dev@... >>>>>>>>>>Betreff: Re: AW: Problems to setup Juice with Windows >>>>>>>>>> >>>>>>>>>>Just started having a look. Is see there is already a project >>>>>>>>>>file for VC++ 6.0 in the old source directory. I'll set up >>>>>>>>>>something in the "standard" "Projects/..." folder structure to get >>>>>>>>>>it going. >>>>>>>>>> >>>>>>>>>>But first I'll get it running under Linux to see how it should >>>>>>>>>>work :>. Having an interesting time getting it to autoconf, but >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>I'll work it >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>out tomorrow night. >>>>>>>>>> >>>>>>>>>>Cheers, >>>>>>>>>> Berin >>>>>>>>>> >>>>>>>>>>Dittmann, Werner wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Berin, >>>>>>>>>>> >>>>>>>>>>>sureI'm open to that. >>>>>>>>>>>The whole native stuff is in plain C, just 5 modules >>>>>>>>>>>in C plus the headers. IMHO I don't use any stuff >>>>>>>>>>>that is Linux specific. >>>>>>>>>>> >>>>>>>>>>>The only prerequistite is the availabilty of the openSSL >>>>>>>>>>>headers and crypto lib. >>>>>>>>>>> >>>>>>>>>>>You can find the sources in incubator/juice/native/srcNew. >>>>>>>>>>> >>>>>>>>>>>If you have ides/questions just send a mail. >>>>>>>>>>> >>>>>>>>>>>Regards, >>>>>>>>>>>Werner >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>-----Ursprüngliche Nachricht----- >>>>>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>>>>>Dienstag, 14. Februar 2006 09:28 >>>>>>>>>>>>An: juice-dev@... >>>>>>>>>>>>Betreff: Re: Problems to setup Juice with Windows >>>>>>>>>>>> >>>>>>>>>>>>Having played with getting things running under Cygwin - I >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>think I'd >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>tend to agree with Scott. It adds some extra complications >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>into the >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>build/run process that could well trip you up. >>>>>>>>>>>> >>>>>>>>>>>>Is it possible to get the stuff to compile on VC++? Are you >>>>>>>>>>>>open for me to have a look to see if I can get it up and >>>>>>>>>>>>running? >>>>>>>>>>>> >>>>>>>>>>>>Cheers, >>>>>>>>>>>> Berin >>>>>>>>>>>> >>>>>>>>>>>>Scott Cantor wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>- using cygwin I was able to setup the autoconf stuff, >>>>>>>>>>>>>>create a >>>>>>>>>>>>>>configure script, and compiled the native sources into a >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>DLL. Before >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>the compile was sucessful I copied the files "jni.h" and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>"jni_md.h" >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>from the Java include directory to /usr/include of >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>cygwin. Then I >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>>>>changed the "typedef __int64 jlong" to "typedef long >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>long jint" to >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>be compliant with gcc. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>Is cygwin the way people would want to use this? I somehow >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>doubt it. Most >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>people on Windows don't wish to pull in the cygwin DLLs, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>they want proper >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>Windows builds. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>Any ideas? Any help is appreciated. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>Regardless of the previous point, is there actual proof >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>that the JVM can >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>load native code built with cygwin? Maybe it just works, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>but I'd try and >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>verify that independently before I went looking for root >>>>>>>>>>>>>causes. >>>>>>>>>>>>> >>>>>>>>>>>>>-- Scott >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>--------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>--------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>--------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>--------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>--------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>--------------------------------------------------------------------- >>>>>>>> >>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>--------------------------------------------------------------------- >>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>>> >>>>> >>>>>--------------------------------------------------------------------- >>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>> >>>> >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>For additional commands, e-mail: juice-dev-help@... >>> >>> >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: juice-dev-unsubscribe@... >>For additional commands, e-mail: juice-dev-help@... >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
|
|
Re: AW: Problems to setup Juice with Windows
by Bugzilla from werner.dittmann@t-online.de
::
Rate this Message:
Berin,
I used Visual C++ Express to test the stuff (without your latest mods of course) and it also worked fine. Looking forward to see your latest updates, Regards, Werner Berin Lautenbach wrote: > Used what you sent me and then updated the jar files - it works > beautifully now under Windows for a VC 6 debug build. I'll also add the > files for release, VC 7 and VC 8 over the next couple of days. > > Nice! > > Cheers, > Berin > > Werner Dittmann wrote: > >> Berin, >> >> usually I also update a signed jar into JuiCE's dist directory. >> >> Regards, >> Werner >> >> Berin Lautenbach wrote: >> >>> Werner, >>> >>> 1st question - am I able to get a copy of the signing keystore for the >>> JAR file? I've done some minor mods, but I cannot test. >>> >>> I took your changes, cleaned up a couple of minor warnings under VC 6.0 >>> and compiled into a new DLL. Of course I then got JNI errors because my >>> JAR was still calling the old methods. >>> >>> I then went and updated the InitializeOpenSSL.java file. Then >>> everything broke completely because my JAR is not signed :>. >>> >>> So I've checked in the slightly cleaned code, and a new version of the >>> project file that includes all the files for a debug build. If I am >>> allowed to get something that allows me to sign the jar that would be >>> fantastic! >>> >>> NOTE - I've *not* checked in my changes to the java code. >>> >>> Cheers, >>> Berin >>> >>> Werner Dittmann wrote: >>> >>> >>>> Berin, >>>> >>>> after looking into the problem I changed the thread locking to use >>>> pthreads on Linux and mutexes for Windows. Pls have a look into the >>>> modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing >>>> Windows maybe tomorrow. >>>> >>>> Regards, >>>> Werner >>>> >>>> Werner Dittmann wrote: >>>> >>>> >>>>> Berin, >>>>> >>>>> thanks for point out the JNIEnv and thread problem - I didn't catch >>>>> that >>>>> while reading the JNI docs. >>>>> >>>>> Well, The idea to use the Jave thread locking was driven to be fully >>>>> interoperable with Java threading :-) ... I'm not sure if for example >>>>> in Linux the pthreads work together with Java. Thus I thought it would >>>>> be a goo idea to use Java's own thread locking - not I have a >>>>> backfire. >>>>> >>>>> I'm going to think about the problem and see how it can be solved. >>>>> >>>>> Regards, >>>>> Werner >>>>> >>>>> >>>>> Berin Lautenbach wrote: >>>>> >>>>> >>>>> >>>>>> Been thinking about this more, so am going to display my complete >>>>>> Java >>>>>> ignorance to ask some silly questions :>. >>>>>> >>>>>> Looking around on the web, I've found that the JNIEnv is thread >>>>>> unique, >>>>>> and it is important not to have one thread use a JNIEnv for another >>>>>> thread. >>>>>> >>>>>> However, the way the initialise works is it checks to see if >>>>>> OPenSSL is >>>>>> already initialised, if not set the global JNIEnv to be the JNIEnv of >>>>>> the current thread. Then it never enters again. >>>>>> >>>>>> However the thread locking function uses the global JNIEnv, which >>>>>> means >>>>>> it doesn't matter what thread calls it, it will always use that >>>>>> JNIEnv. >>>>>> That appears on the surface to be incorrect behaviour. >>>>>> >>>>>> Have I got this up wrong? >>>>>> >>>>>> Also, why do we use the Java thread locking system for OpenSSL? >>>>>> Is the >>>>>> normal OpenSSL system inadequate in the Java environment? >>>>>> >>>>>> Cheers, >>>>>> Berin >>>>>> >>>>>> Berin Lautenbach wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> OK - I know what's causing it, but my knowledge of JNI is not good >>>>>>> enough for me to work out the best way to fix it. >>>>>>> >>>>>>> enabling -Xcheck:jni on the jvm call showed that the JEnv is being >>>>>>> called by a non-java thread. >>>>>>> >>>>>>> By doing some tracing, I worked out that java_locking_callback is >>>>>>> being called *after* junit has completed. >>>>>>> >>>>>>> My belief is that this is because the OpenSSL library shuts down on >>>>>>> program exit. Because Java.exe is the program the DLL is hooked to, >>>>>>> this is happening long after java has shut down the actual java >>>>>>> environment. >>>>>>> >>>>>>> Assuming I'm correct, we need to do one of the following: >>>>>>> >>>>>>> 1. Have the provider shut down OpenSSL prior to everything >>>>>>> finishing. >>>>>>> 2. Have the program shut down OpenSSL prior to exitting - i.e. user >>>>>>> responsibility (still need to implement the function to do this) >>>>>>> 3. Have a check within the java_locking_callback that sees whether >>>>>>> the JEnv is valid, and doesn't call it if it's not. >>>>>>> >>>>>>> Of the options, my favourite is 1 - is there some provider function >>>>>>> that we can hook into here? Not guaranteed to work, there might be >>>>>>> some locking calls that OpenSSL has to do on exit that we cannot >>>>>>> pre-empt. >>>>>>> >>>>>>> Option 2 is horrible. Last case only. >>>>>>> >>>>>>> Option 3 is not the best, but will work if all else fails. We might >>>>>>> be able to mix it with Option 1 - i.e. when the provider de-inits, >>>>>>> call a function that unregisters the locking function in OpenSSL. >>>>>>> >>>>>>> Open to thoughts. Happy to do the implementation, but as I said, >>>>>>> not >>>>>>> enough of a JNI or provider expert to know which is the best option. >>>>>>> >>>>>>> Cheers, >>>>>>> Berin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dittmann, Werner wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Berin, >>>>>>>> >>>>>>>> thanks for the setup of the VC 6.0 project. After downloading >>>>>>>> a Visual C++ Express environment (MS provides that free of >>>>>>>> charge for everybody :-) ) plus the Platform SDK, thus installing >>>>>>>> about 2GB of MS development environment I was able to build >>>>>>>> the openSSL4Java.dll starting with your project files. >>>>>>>> >>>>>>>> Running the same test results in the same error. The Package >>>>>>>> test terminated after 23 tests (I added 2 more tests for >>>>>>>> SecureRandom). >>>>>>>> The result was a memory access violation. >>>>>>>> The I started a standalone test with the same result - but only >>>>>>>> after >>>>>>>> all tests were done. This made me believe it has something to do >>>>>>>> with >>>>>>>> process termination. Just as a simple test I added a System.exit(0) >>>>>>>> call as the last line of the Package.java main method - and voila >>>>>>>> - no >>>>>>>> more memory access error. >>>>>>>> >>>>>>>> As an additional test I forced one unit test to fail - also this >>>>>>>> works as expected: it reports the failures and terminates without >>>>>>>> memory access violation (after System.exit(0) was added. >>>>>>>> >>>>>>>> Because Java starts some threads internaly and tries to terminate >>>>>>>> them in an orderly fashion - could it a threading problem? >>>>>>>> >>>>>>>> I just updated package.java and OpenSSLTestBlock.java to call >>>>>>>> System.exit(0). IMHO we should try to drill down on the problem. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Werner >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>> Mittwoch, 15. Februar 2006 11:30 >>>>>>>>> An: juice-dev@... >>>>>>>>> Betreff: Re: AW: AW: Problems to setup Juice with Windows >>>>>>>>> >>>>>>>>> The autogen problem was me Debian installing automake 1.4 by >>>>>>>>> default(!) Once I had 1.9 everything was cool. >>>>>>>>> >>>>>>>>> I have imported a *very* basic debug build for VC 6.0 into the >>>>>>>>> repo. >>>>>>>>> There are some interesting complile time messages that I will look >>>>>>>>> at, but I get 21 tests run successfully before I get a rather >>>>>>>>> nasty >>>>>>>>> memory access violation. I'll sort that one out in a few days as >>>>>>>>> well :>. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Berin >>>>>>>>> >>>>>>>>> Dittmann, Werner wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Berin, >>>>>>>>>> >>>>>>>>>> this project file is for the old juice native software. Pls >>>>>>>>>> be informed that I introduced a new setup for Juice. >>>>>>>>>> >>>>>>>>>> The autoconf under Linux should simply work. Have a look >>>>>>>>>> the the configure.ac and tha Makefile.am files, but running >>>>>>>>>> ./configure should work (if zou download the GZ file), otherwise >>>>>>>>>> just run the autogen.sh script. This creates all necessary >>>>>>>>>> files and runs ./configure. After "make" the shared lib >>>>>>>>>> is in srcNew/.libs. >>>>>>>>>> >>>>>>>>>> Don't forget to set LD_LIBRARY_PATH correctly for the test >>>>>>>>>> cases. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Werner >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet: >>>>>>>>>>> Dienstag, 14. Februar 2006 10:27 >>>>>>>>>>> An: juice-dev@... >>>>>>>>>>> Betreff: Re: AW: Problems to setup Juice with Windows >>>>>>>>>>> >>>>>>>>>>> Just started having a look. Is see there is already a project >>>>>>>>>>> file for VC++ 6.0 in the old source directory. I'll set up >>>>>>>>>>> something in the "standard" "Projects/..." folder structure >>>>>>>>>>> to get >>>>>>>>>>> it going. >>>>>>>>>>> >>>>>>>>>>> But first I'll get it running under Linux to see how it should >>>>>>>>>>> work :>. Having an interesting time getting it to autoconf, but >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll work it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> out tomorrow night. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Berin >>>>>>>>>>> >>>>>>>>>>> Dittmann, Werner wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Berin, >>>>>>>>>>>> >>>>>>>>>>>> sureI'm open to that. >>>>>>>>>>>> The whole native stuff is in plain C, just 5 modules >>>>>>>>>>>> in C plus the headers. IMHO I don't use any stuff >>>>>>>>>>>> that is Linux specific. >>>>>>>>>>>> >>>>>>>>>>>> The only prerequistite is the availabilty of the openSSL >>>>>>>>>>>> headers and crypto lib. >>>>>>>>>>>> >>>>>>>>>>>> You can find the sources in incubator/juice/native/srcNew. >>>>>>>>>>>> >>>>>>>>>>>> If you have ides/questions just send a mail. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Werner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Ursprüngliche Nachricht----- >>>>>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] >>>>>>>>>>>>> Gesendet: >>>>>>>>>>>>> Dienstag, 14. Februar 2006 09:28 >>>>>>>>>>>>> An: juice-dev@... >>>>>>>>>>>>> Betreff: Re: Problems to setup Juice with Windows >>>>>>>>>>>>> >>>>>>>>>>>>> Having played with getting things running under Cygwin - I >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> think I'd >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> tend to agree with Scott. It adds some extra complications >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> into the >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> build/run process that could well trip you up. >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible to get the stuff to compile on VC++? Are you >>>>>>>>>>>>> open for me to have a look to see if I can get it up and >>>>>>>>>>>>> running? >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Berin >>>>>>>>>>>>> >>>>>>>>>>>>> Scott Cantor wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> - using cygwin I was able to setup the autoconf stuff, >>>>>>>>>>>>>>> create a >>>>>>>>>>>>>>> configure script, and compiled the native sources into a >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> DLL. Before >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> the compile was sucessful I copied the files "jni.h" and >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> "jni_md.h" >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> from the Java include directory to /usr/include of >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> cygwin. Then I >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>> changed the "typedef __int64 jlong" to "typedef long >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> long jint" to >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>> be compliant with gcc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is cygwin the way people would want to use this? I somehow >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> doubt it. Most >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> people on Windows don't wish to pull in the cygwin DLLs, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> they want proper >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Windows builds. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any ideas? Any help is appreciated. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regardless of the previous point, is there actual proof >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> that the JVM can >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> load native code built with cygwin? Maybe it just works, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> but I'd try and >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> verify that independently before I went looking for root >>>>>>>>>>>>>> causes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Scott >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>> juice-dev-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>>> For additional commands, e-mail: juice-dev-help@... >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>>> For additional commands, e-mail: juice-dev-help@... >>>>> >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>>> For additional commands, e-mail: juice-dev-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: juice-dev-unsubscribe@... >>> For additional commands, e-mail: juice-dev-help@... >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: juice-dev-unsubscribe@... >> For additional commands, e-mail: juice-dev-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: juice-dev-unsubscribe@... > For additional commands, e-mail: juice-dev-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: juice-dev-unsubscribe@... For additional commands, e-mail: juice-dev-help@... |
| Free embeddable forum powered by Nabble | Forum Help |
