Re: [Wrapper-user] JVM crash using wrapper and custom JNI

[Leif M. <le...@ta...>]

Jason,
    The Wrapper tries to shutdown the application as closely to the 
normal way as
possible, but there are some slight timing differences during the 
shutdown process.
My guess is that it is a timing problem of some sort.

    There are a lot of programs using JNI code that run without problem 
under the
Wrapper, so until I see further evidence, I think we should assume for 
now that it
is a problem in your code.

    You are correct that debugging JNI code can be a bit of pain.  The 
method that
I usually use that is actually the most efficient is to place a bunch of 
printf statements
in your code and then see exactly what is happening.  The problem is 
that something
with the way Java works causes printf output not to be sent to the console
immediately.  This means that whatever happens right before a crash will 
be lost.
The fix is to add a flushall(); call right after the printf();  Not 
efficient performance wise,
but it works.

    For example:
printf("releaseSAVI() 1\n"); flushall();

    You are getting an access violation, so most likely you are trying 
to access a
null pointer or a pointer to memory that has already been freed.   Make 
sure that
you are only calling your cleanup code once.   Add debug output at the 
entry and
exit point to all of your native functions without making any assumptions.
Hopefully one of those things will make the cause pop out.

    How many threads are accessing your code.  synchronization problems 
are a
common cause of crashes in C.  The printf s at the entry and exit of 
each function
might make this cause obvious.

    One more possible difference.   Make sure that you are running the 
correct
JVM.   Most people have their wrapper.conf set up to locate the java exe 
on the
system path.   The path when running as a service is often different 
than that from
a console.   You may for example be running Java 1.4 as a service, but 
1.5 when
run standalone from a batch file.   If you set the wrapper.debug=true 
property,
you can see exactly what is being run as the Wrapper launches the JVM.

Cheers,
Leif

Jason Polites wrote:
> Hello all,
>
> I am using the wrapper to launch a java app which loads a native 
> library of my own creation.  When running outside the wrapper, my 
> native code initialises and terminates successfully, and always has.  
> When I run this same app within the wrapper, the JVM crashes when I am 
> terminating my native resource.
>
> The native code I have is loading a COM DLL, and when my java app 
> closes it releases an unloads the COM DLL.  It is during this process 
> that I get the JVM crash.
>
> Crash details are:
>
> jvm 1    | #
> jvm 1    | # An unexpected error has been detected by HotSpot Virtual 
> Machine:
> jvm 1    | #
> jvm 1    | #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at 
> pc=0x1900507f, pid=1168, tid=3016
> jvm 1    | #
> jvm 1    | # Java VM: Java HotSpot(TM) Server VM (1.5.0_09-b01 mixed mode)
> jvm 1    | # Problematic frame:
> jvm 1    | # C
> jvm 1    |   [JSAVI2.dll+0xb507f]
> jvm 1    | #
> jvm 1    | # An error report file with more information is saved as 
> hs_err_pid1168.log
> jvm 1    | #
> jvm 1    | # If you would like to submit a bug report, please visit:
> jvm 1    | #   http://java.sun.com/webapps/bugreport/crash.jsp
> jvm 1    | #
> wrapper  | JVM exited unexpectedly while stopping the application.
>
> You will see that the "Problematic frame" is reported as JSAVI2.dll.  
> This is my native DLL which loads/unloads the COM DLL.
>
> The call stack in the JVM error report looks like this:
>
> Stack: [0x19780000,0x197c0000),  sp=0x197bee20,  free space=251k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> C  [JSAVI2.dll+0xb507f]
> C  [JSAVI2.dll+0xb7259]
> j  
> com.synetek.virus.scanner.JSavi.releaseSAVI(Lcom/synetek/virus/scanner/ScannerLog;)V+0 
>
> j  
> com.synetek.virus.scanner.JSavi.destroy(Lcom/synetek/virus/scanner/ScannerLog;)V+9
> j  com.synetek.everymail.core.handler.PipelineHandler.destroy()V+27
> j  com.synetek.event.EventProcessor.destroy()V+43
> j  com.synetek.processor.MultiProcessor.destroy (J)V+41
> j  com.synetek.processor.ManagedMultiProcessor.stop(J)V+9
> j  com.synetek.everymail.core.pipeline.poll.PipelinePoller.destroy()V+12
> j  com.synetek.poller.AbstractPoller.stop(J)V+78
> j  com.synetek.poller.remote.RemoteController.stop (J)V+5
> v  ~StubRoutines::call_stub
> V  [jvm.dll+0xf96e0]
>
> You can see that my call to "releaseSAVI" is where the crash occurs. 
>
> Ordinarily I would assume that there is something wrong with my DLL, 
> but it has been working correctly until now.  I have checked and 
> double-checked the implementation of this native method in the C++ 
> code and I cannot see how or why I should be experiencing any problems 
> (the native method is only 3 lines of code!).
>
> As stated, when I run my app in straight java land all is well.  I 
> have tried to debug my JNI DLL from Visual Studio, but the only way I 
> know to do this is to "attach" to the java.exe process from within 
> Visual Studio.  Problem is that because java.exe crashes I don't get 
> an opportunity to step through the execution of the native code.
>
> I'm a bit stuck here as there doesn't appear to be anything I can to 
> short of not using the wrapper.  This leaves me in the unenviable 
> position of having to write my own (urgh).
>
> Have tried disabling HotSpot.. same problem.
>
> Anyone have any ideas?
>
> Thanks.