Problems to setup Juice with Windows

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems to setup Juice with Windows

Dittmann, Werner
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Problems to setup Juice with Windows

Cantor, Scott
> - 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problems to setup Juice with Windows

Berin Lautenbach
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Problems to setup Juice with Windows

Raul Benito-2
In reply to this post by Cantor, Scott
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://r-bg.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: Problems to setup Juice with Windows

Dittmann, Werner
In reply to this post by Dittmann, Werner
Scott,

thanks for the hints.

Well, I never thought it could be a problem to load a
DLL built with cygwin/GCC with another native Windows
process - I believed Windows is Windows is Windows :))
(I've no Windows dev envirnomet on my systems)

But I'll try to find people with native Windows
dev envirnment that can produce a "real" DLL.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Scott Cantor [mailto:[hidden email]]
> Gesendet: Montag, 13. Februar 2006 17:24
> An: [hidden email]
> Betreff: RE: Problems to setup Juice with Windows
>
> > - 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: Problems to setup Juice with Windows

Dittmann, Werner
In reply to this post by Dittmann, Werner
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:[hidden email]]
> Gesendet: Dienstag, 14. Februar 2006 09:28
> An: [hidden email]
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: Problems to setup Juice with Windows

Berin Lautenbach
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:[hidden email]]
>>Gesendet: Dienstag, 14. Februar 2006 09:28
>>An: [hidden email]
>>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: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: AW: Problems to setup Juice with Windows

Dittmann, Werner
In reply to this post by Dittmann, Werner
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:[hidden email]]
> Gesendet: Dienstag, 14. Februar 2006 10:27
> An: [hidden email]
> 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:[hidden email]]
> >>Gesendet: Dienstag, 14. Februar 2006 09:28
> >>An: [hidden email]
> >>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: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: Problems to setup Juice with Windows

Berin Lautenbach
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:[hidden email]]
>>Gesendet: Dienstag, 14. Februar 2006 10:27
>>An: [hidden email]
>>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:[hidden email]]
>>>>Gesendet: Dienstag, 14. Februar 2006 09:28
>>>>An: [hidden email]
>>>>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: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>
>>>>------------------------------------------------------------
>>
>>---------
>>
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: AW: AW: Problems to setup Juice with Windows

Dittmann, Werner
In reply to this post by Dittmann, Werner
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:[hidden email]]
> Gesendet: Mittwoch, 15. Februar 2006 11:30
> An: [hidden email]
> 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:[hidden email]]
> >>Gesendet: Dienstag, 14. Februar 2006 10:27
> >>An: [hidden email]
> >>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:[hidden email]]
> >>>>Gesendet: Dienstag, 14. Februar 2006 09:28
> >>>>An: [hidden email]
> >>>>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: [hidden email]
> >>>>>For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>------------------------------------------------------------
> >>
> >>---------
> >>
> >>>>To unsubscribe, e-mail: [hidden email]
> >>>>For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>------------------------------------------------------------
> ---------
> >>
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: AW: Problems to setup Juice with Windows

Berin Lautenbach
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:[hidden email]]
>>Gesendet: Mittwoch, 15. Februar 2006 11:30
>>An: [hidden email]
>>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:[hidden email]]
>>>>Gesendet: Dienstag, 14. Februar 2006 10:27
>>>>An: [hidden email]
>>>>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:[hidden email]]
>>>>>>Gesendet: Dienstag, 14. Februar 2006 09:28
>>>>>>An: [hidden email]
>>>>>>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: [hidden email]
>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>------------------------------------------------------------
>>>>
>>>>---------
>>>>
>>>>
>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>------------------------------------------------------------
>>
>>---------
>>
>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>
>>>>------------------------------------------------------------
>>
>>---------
>>
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: AW: Problems to setup Juice with Windows

Berin Lautenbach
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:[hidden email]] Gesendet:
>>> Mittwoch, 15. Februar 2006 11:30
>>> An: [hidden email]
>>> 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:[hidden email]] Gesendet:
>>>>> Dienstag, 14. Februar 2006 10:27
>>>>> An: [hidden email]
>>>>> 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:[hidden email]] Gesendet:
>>>>>>> Dienstag, 14. Februar 2006 09:28
>>>>>>> An: [hidden email]
>>>>>>> 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: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>
>>>>>
>>>>> ---------
>>>>>
>>>>>
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------
>>>
>>>
>>> ---------
>>>
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>
>>>
>>> ---------
>>>
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: AW: AW: Problems to setup Juice with Windows

Werner Dittmann
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:[hidden email]] Gesendet:
>>>> Mittwoch, 15. Februar 2006 11:30
>>>> An: [hidden email]
>>>> 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:[hidden email]] Gesendet:
>>>>>> Dienstag, 14. Februar 2006 10:27
>>>>>> An: [hidden email]
>>>>>> 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:[hidden email]] Gesendet:
>>>>>>>> Dienstag, 14. Februar 2006 09:28
>>>>>>>> An: [hidden email]
>>>>>>>> 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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------
>>>>>>
>>>>>>
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> ---------
>>>>
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> ---------
>>>>
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: Problems to setup Juice with Windows

Werner Dittmann
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:[hidden email]] Gesendet:
>>>>>Mittwoch, 15. Februar 2006 11:30
>>>>>An: [hidden email]
>>>>>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:[hidden email]] Gesendet:
>>>>>>>Dienstag, 14. Februar 2006 10:27
>>>>>>>An: [hidden email]
>>>>>>>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:[hidden email]] Gesendet:
>>>>>>>>>Dienstag, 14. Februar 2006 09:28
>>>>>>>>>An: [hidden email]
>>>>>>>>>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: [hidden email]
>>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>---------
>>>>>
>>>>>
>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>---------
>>>>>
>>>>>
>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: Problems to setup Juice with Windows

Berin Lautenbach
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:[hidden email]] Gesendet:
>>>>>>Mittwoch, 15. Februar 2006 11:30
>>>>>>An: [hidden email]
>>>>>>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:[hidden email]] Gesendet:
>>>>>>>>Dienstag, 14. Februar 2006 10:27
>>>>>>>>An: [hidden email]
>>>>>>>>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:[hidden email]] Gesendet:
>>>>>>>>>>Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>An: [hidden email]
>>>>>>>>>>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: [hidden email]
>>>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>---------
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>---------
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: Problems to setup Juice with Windows

Werner Dittmann
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:[hidden email]] Gesendet:
>>>>>>> Mittwoch, 15. Februar 2006 11:30
>>>>>>> An: [hidden email]
>>>>>>> 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:[hidden email]] Gesendet:
>>>>>>>>> Dienstag, 14. Februar 2006 10:27
>>>>>>>>> An: [hidden email]
>>>>>>>>> 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:[hidden email]] Gesendet:
>>>>>>>>>>> Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>> An: [hidden email]
>>>>>>>>>>> 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: [hidden email]
>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: Problems to setup Juice with Windows

Berin Lautenbach
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:[hidden email]] Gesendet:
>>>>>>>>Mittwoch, 15. Februar 2006 11:30
>>>>>>>>An: [hidden email]
>>>>>>>>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:[hidden email]] Gesendet:
>>>>>>>>>>Dienstag, 14. Februar 2006 10:27
>>>>>>>>>>An: [hidden email]
>>>>>>>>>>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:[hidden email]] Gesendet:
>>>>>>>>>>>>Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>>>An: [hidden email]
>>>>>>>>>>>>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: [hidden email]
>>>>>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>---------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>>For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: AW: Problems to setup Juice with Windows

Werner Dittmann
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:[hidden email]] Gesendet:
>>>>>>>>> Mittwoch, 15. Februar 2006 11:30
>>>>>>>>> An: [hidden email]
>>>>>>>>> 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:[hidden email]] Gesendet:
>>>>>>>>>>> Dienstag, 14. Februar 2006 10:27
>>>>>>>>>>> An: [hidden email]
>>>>>>>>>>> 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:[hidden email]]
>>>>>>>>>>>>> Gesendet:
>>>>>>>>>>>>> Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>>>> An: [hidden email]
>>>>>>>>>>>>> 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: [hidden email]
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]