JVM dies when JNI native code causes a SIGABRT from assertions

Hi,
I am wondering whether there is a way to prevent the JVM from dying when the JNI native code hits an assertion.
#include "NativeTest.h"
#include <assert.h>
JNIEXPORT jstring JNICALL Java_NativeTest_sayHello (JNIEnv *env, jobject thisobject, jstring js)
assert(0);
return js;
Calling this code from Java through JNI causes a SIGABRT when assert(0) is hit. This causes the java program to terminate. Is there a way for the JVM to recover from the SIGABRT from the native code?

929919 wrote:
I am wondering whether there is a way to prevent the JVM from dying when the JNI native code hits an assertion.There is no way to prevent the VM from exiting if native code does anything that causes an exit.
An assertion is only one way that can happen.
So to prevent the VM from exiting - don't run native code. The safe way to execute OS native library is to do the following.
1. Wrap the library in an executable.
2. Create a communications API for the executable.
3. Manage the executable via Java Runtime.exec/ProcessBuilder.
4. Talk to the executable using the communications API from 2 in the java code.
The above is safe because if the library exits it exits the executable, not the VM.

Similar Messages

  • Calling existing C++ dll from native code causes an ACCESS_VIOLATION

    Hi everyone,
    I'm having issues creating a Java app to call an existing c++ DLL. I've done extensive searching for a solution and found lots of goodies, but nothing to fix my problem yet.
    I've gone through the JNI tutorial and created my java class, used javah, and created my native code according to the tutorial.
    I'm new to dealing with DLLs so I'm not sure if there are some steps that I'm not taking.
    The issue comes when I run the program. I get an EXCEPTION_ACCESS_VIOLATION.
    the DLL I'm trying to call makes a call to a device on the USB port. I also have the source code and header files for the DLL but thought it would be easier to just have to deal with the already built DLL.
    After putting some print statements in the native function, the violation comes when I try to call the function in the external DLL. The DLL itself loads correctly (as far as I know).
    Here my native method that will load the external dll. I got the code to call the DLL method from:
    http://goff.nu/techarticles/development/cpp/calldll.html
    JNIEXPORT void JNICALL
    Java_OCPMControl_OCPMSetPixelCount (JNIEnv *env, jobject obj, jint pixelCount)
    //load the dll
    HINSTANCE ocpmSerialDLL = LoadLibrary("OCPMSerialDLL");
    /* get pointer to the function in the dll*/
    FARPROC myDLLFunction = GetProcAddress(HMODULE(ocpmSerialDLL), "OCPMSetPixelCount");
    /* Define the Function in the DLL for reuse. This is just prototyping
    * the dll's function. A mock of it. Use "stdcall" for maximum compatibility.
    typedef void (__stdcall * FUNC)(enum ePixelNum);
    FUNC MyFunction;
    MyFunction = FUNC(myDLLFunction);
    printf("Calling function\n");
    /* The actual call to the function contained in the dll */
    MyFunction(PIXEL256);
    /* Release the Dll */
    FreeLibrary(ocpmSerialDLL);
    When I run the program, I get the following error:
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x182
    91E6B
    Function=[Unknown.]
    Library=C:\sun\MyJava\ocpm\src\OCPMSerialDLL.dll
    NOTE: We are unable to locate the function name symbol for the error
    just occurred. Please refer to release documentation for possible
    reason and solutions.
    Current Java thread:
    at OCPMControl.OCPMSetPixelCount(Native Method)
    at OCPMControl.getData(OCPMControl.java:167)
    at OCPMService.main(OCPMService.java:46)
    Dynamic libraries:
    0x00400000 - 0x00406000 c:\sun\j2sdk1.4.2_03\bin\java.exe
    0x77F80000 - 0x77FFD000 C:\WINNT\system32\ntdll.dll
    0x7C2D0000 - 0x7C332000 C:\WINNT\system32\ADVAPI32.dll
    0x7C570000 - 0x7C628000 C:\WINNT\system32\KERNEL32.DLL
    0x77D30000 - 0x77DA1000 C:\WINNT\system32\RPCRT4.DLL
    0x78000000 - 0x78045000 C:\WINNT\system32\MSVCRT.dll
    0x08000000 - 0x08138000 c:\sun\j2sdk1.4.2_03\jre\bin\client\jvm.dll
    0x77E10000 - 0x77E75000 C:\WINNT\system32\USER32.dll
    0x77F40000 - 0x77F7E000 C:\WINNT\system32\GDI32.DLL
    0x77570000 - 0x775A0000 C:\WINNT\system32\WINMM.dll
    0x10000000 - 0x10007000 c:\sun\j2sdk1.4.2_03\jre\bin\hpi.dll
    0x007C0000 - 0x007CE000 c:\sun\j2sdk1.4.2_03\jre\bin\verify.dll
    0x007D0000 - 0x007E9000 c:\sun\j2sdk1.4.2_03\jre\bin\java.dll
    0x007F0000 - 0x007FD000 c:\sun\j2sdk1.4.2_03\jre\bin\zip.dll
    0x18270000 - 0x1827E000 C:\sun\MyJava\ocpm\src\OCPMNative.dll
    0x18290000 - 0x182AA000 C:\sun\MyJava\ocpm\src\OCPMSerialDLL.dll
    0x68120000 - 0x681A1000 C:\sun\MyJava\ocpm\src\instrsup.dll
    0x76B30000 - 0x76B6E000 C:\WINNT\system32\comdlg32.dll
    0x70A70000 - 0x70AD5000 C:\WINNT\system32\SHLWAPI.DLL
    0x71710000 - 0x71794000 C:\WINNT\system32\COMCTL32.DLL
    0x782F0000 - 0x78538000 C:\WINNT\system32\SHELL32.DLL
    0x77920000 - 0x77943000 C:\WINNT\system32\imagehlp.dll
    0x72A00000 - 0x72A2D000 C:\WINNT\system32\DBGHELP.dll
    0x690A0000 - 0x690AB000 C:\WINNT\system32\PSAPI.DLL
    Heap at VM Abort:
    Heap
    def new generation total 576K, used 140K [0x10010000, 0x100b0000, 0x104f0000)
    eden space 512K, 27% used [0x10010000, 0x10033368, 0x10090000)
    from space 64K, 0% used [0x10090000, 0x10090000, 0x100a0000)
    to space 64K, 0% used [0x100a0000, 0x100a0000, 0x100b0000)
    tenured generation total 1408K, used 0K [0x104f0000, 0x10650000, 0x14010000)
    the space 1408K, 0% used [0x104f0000, 0x104f0000, 0x104f0200, 0x10650000)
    compacting perm gen total 4096K, used 1012K [0x14010000, 0x14410000, 0x1801000
    0)
    the space 4096K, 24% used [0x14010000, 0x1410d1f0, 0x1410d200, 0x14410000)
    Local Time = Wed May 12 10:53:56 2004
    Elapsed Time = 10
    # The exception above was detected in native code outside the VM
    # Java VM: Java HotSpot(TM) Client VM (1.4.2_03-b02 mixed mode)
    # An error report file has been saved as hs_err_pid2120.log.
    # Please refer to the file for further information.
    Is there something else I have to do to tell the JVM that the external DLL call isn't an Access Violation?
    Would it be easier to use the source files instead?
    Thanks to anyone who can help me out here!
    Scott Campbell

    Thanks,
    The problem has been solved. I wasn't linking the dll properly to access the external DLL and thus, my native DLL was looking for methods that it didn't know how to find. which was easily solved by adding a few options when creating my native dll.
    Here is the link I found to solve the problem incase anyone else has issues like this. It is regarding implicit v.s. explicit linking to external DLLs in using visual C++.
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_link_an_executable_to_a_dll.asp
    Scott.

  • Exception in native code causing Tomcat to crash

    I am running a java servlet on Tomcat and have noticed that it has been unexpectedly terminating quite a bit over the last month or so. Yesterday it happened twice, citing an exception in native code outside the VM. I really have no idea where to start debugging this. Below is what is in the log file that is generated when it terminates. Does anybody know why something like this would be happening? Looking at the stack trace, it looks like a strange place to be terminating? Has anybody come accross anything like this? If you need more information, let me know!
    Thanks!!!
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x77F4200B
    Function=RtlEnterCriticalSection+0xB
    Library=C:\WINDOWS\system32\ntdll.dll
    Current Java thread:
    at sun.jdbc.odbc.JdbcOdbc.allocConnect(Native Method)
    at sun.jdbc.odbc.JdbcOdbc.SQLAllocConnect(JdbcOdbc.java:114)
    at sun.jdbc.odbc.JdbcOdbcDriver.allocConnection(JdbcOdbcDriver.java:929)
    at sun.jdbc.odbc.JdbcOdbcConnection.initialize(JdbcOdbcConnection.java:126)
    at sun.jdbc.odbc.JdbcOdbcDriver.connect(JdbcOdbcDriver.java:174)
    - locked <02F7D2F0> (a sun.jdbc.odbc.JdbcOdbcDriver)
    at java.sql.DriverManager.getConnection(DriverManager.java:512)
    - locked <06A87EB0> (a java.lang.Class)
    at java.sql.DriverManager.getConnection(DriverManager.java:193)
    - locked <06A87EB0> (a java.lang.Class)
    at com.lmp.iomada.servlets.LMPPersistence.buildObjects(LMPPersistence.java:56)
    at com.lmp.iomada.servlets.LMPServlet.transformHTML(LMPServlet.java:635)
    at com.lmp.iomada.servlets.LMPServlet.doGet(LMPServlet.java:71)
    at com.lmp.iomada.servlets.LMPServlet.doPost(LMPServlet.java:82)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java)
    at org.apache.tomcat.facade.ServletHandler.doService(Unknown Source)
    at org.apache.tomcat.core.Handler.invoke(Unknown Source)
    at org.apache.tomcat.core.Handler.service(Unknown Source)
    at org.apache.tomcat.facade.ServletHandler.service(Unknown Source)
    at org.apache.tomcat.core.ContextManager.internalService(Unknown Source)
    at org.apache.tomcat.core.ContextManager.service(Unknown Source)
    at org.apache.tomcat.modules.server.Ajp12Interceptor.processConnection(Unknown Source)
    at org.apache.tomcat.util.net.TcpWorkerThread.runIt(Unknown Source)
    at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:536)
    Dynamic libraries:
    0x00400000 - 0x00406000 c:\j2sdk1.4.1_03\bin\java.exe
    0x77F40000 - 0x77FFA000 C:\WINDOWS\system32\ntdll.dll
    0x77E40000 - 0x77F34000 C:\WINDOWS\system32\kernel32.dll
    0x77DA0000 - 0x77E30000 C:\WINDOWS\system32\ADVAPI32.dll
    0x77C50000 - 0x77CF5000 C:\WINDOWS\system32\RPCRT4.dll
    0x77BA0000 - 0x77BF4000 C:\WINDOWS\system32\MSVCRT.dll
    0x6D340000 - 0x6D46B000 c:\j2sdk1.4.1_03\jre\bin\client\jvm.dll
    0x77D00000 - 0x77D8F000 C:\WINDOWS\system32\USER32.dll
    0x77C00000 - 0x77C44000 C:\WINDOWS\system32\GDI32.dll
    0x76AA0000 - 0x76ACC000 C:\WINDOWS\system32\WINMM.dll
    0x6D1E0000 - 0x6D1E7000 c:\j2sdk1.4.1_03\jre\bin\hpi.dll
    0x6D310000 - 0x6D31E000 c:\j2sdk1.4.1_03\jre\bin\verify.dll
    0x6D220000 - 0x6D239000 c:\j2sdk1.4.1_03\jre\bin\java.dll
    0x6D330000 - 0x6D33D000 c:\j2sdk1.4.1_03\jre\bin\zip.dll
    0x76F50000 - 0x76F63000 C:\WINDOWS\system32\Secur32.dll
    0x6D2E0000 - 0x6D2EE000 C:\j2sdk1.4.1_03\jre\bin\net.dll
    0x71BB0000 - 0x71BB9000 C:\WINDOWS\system32\WSOCK32.dll
    0x71C00000 - 0x71C18000 C:\WINDOWS\system32\WS2_32.dll
    0x71BF0000 - 0x71BF8000 C:\WINDOWS\system32\WS2HELP.dll
    0x71B20000 - 0x71B63000 C:\WINDOWS\system32\mswsock.dll
    0x71AE0000 - 0x71AE8000 C:\WINDOWS\System32\wshtcpip.dll
    0x6D260000 - 0x6D26B000 C:\j2sdk1.4.1_03\jre\bin\JdbcOdbc.dll
    0x0B3E0000 - 0x0B41A000 C:\WINDOWS\system32\ODBC32.dll
    0x70BC0000 - 0x70C50000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.0.0_x-ww_8A69BA05\COMCTL32.dll
    0x77380000 - 0x77B5D000 C:\WINDOWS\system32\SHELL32.dll
    0x77290000 - 0x772D9000 C:\WINDOWS\system32\SHLWAPI.dll
    0x762B0000 - 0x762F7000 C:\WINDOWS\system32\comdlg32.dll
    0x70AD0000 - 0x70BB6000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.100.0_x-ww_8417450B\comctl32.dll
    0x0B580000 - 0x0B597000 C:\WINDOWS\system32\odbcint.dll
    0x0B720000 - 0x0B73A000 C:\WINDOWS\system32\odbccp32.dll
    0x77160000 - 0x77285000 C:\WINDOWS\system32\ole32.dll
    0x77B90000 - 0x77B98000 C:\WINDOWS\system32\VERSION.dll
    0x76ED0000 - 0x76EF7000 C:\WINDOWS\system32\DNSAPI.dll
    0x76F70000 - 0x76F77000 C:\WINDOWS\System32\winrnr.dll
    0x76F10000 - 0x76F3F000 C:\WINDOWS\system32\WLDAP32.dll
    0x76F80000 - 0x76F85000 C:\WINDOWS\system32\rasadhlp.dll
    0x0FFD0000 - 0x0FFFD000 C:\WINDOWS\system32\rsaenh.dll
    0x76B70000 - 0x76B7B000 C:\WINDOWS\system32\PSAPI.DLL
    0x76C10000 - 0x76C38000 C:\WINDOWS\system32\imagehlp.dll
    0x6D580000 - 0x6D621000 C:\WINDOWS\system32\dbghelp.dll
    Local Time = Tue Jun 01 21:23:49 2004
    Elapsed Time = 5644
    # The exception above was detected in native code outside the VM
    # Java VM: Java HotSpot(TM) Client VM (1.4.1_03-b02 mixed mode)

    Library=C:\WINDOWS\system32\ntdll.dll
    Current Java thread:
    at sun.jdbc.odbc.JdbcOdbc.allocConnect(Native Method)
    at sun.jdbc.odbc.JdbcOdbc.SQLAllocConnect(JdbcOdbc.java:114)
    at sun.jdbc.odbc.JdbcOdbcDriver.allocConnection(JdbcOdbcDriver.java:929)
    at sun.jdbc.odbc.JdbcOdbcConnection.initialize(JdbcOdbcConnection.java:126)
    at sun.jdbc.odbc.JdbcOdbcDriver.connect(JdbcOdbcDriver.java:174)
    The stack trace points to an error in ntdll.dll, the NT system calls library, while it being used by Sun's standard ODBC driver.
    There are two unfixed bugs against 1.4 in this area. One suggests incorrect usage of the driver by client code. The other suggests that the current Java library has poor handling of exceptions in system code.
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4812268
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4641011
    The latter does not explort the actual cause of exceptions - they will have something to do with your Windows configuration. Applying the latest NT service packs might help. Unfortunately as the bug report indicates, this issue will not be fixed in 1.4.

  • GUI crashes when calling native code..

    Hi,
    I have interfaced to an existing C program using the Java Native Interface and I am controlling the C program using a GUI. The problem is that everytime I click on the button to call the native method, the GUI crashes... The bizarre thing is that the C code seems to actually execute properly and no exceptions are thrown..
    Anyone come across this problem?
    /john

    Hi,
    Thanks for the replies...
    The GUI completely disappears. No error file is generated. No exceptions are thrown. Here it is in more detail..
    The C code is invoked using the java native interface. The C code converts a MIDI file to a text file. It is normally run in DOS and accepts two parameters. You would run it in DOS normally as follows:
    mf2t Example1.mid Example1.txt.
    In the GUI I select the MIDI file and specify the output file (Example1.txt). I then pass these two parameters to the C code. The C code originally used argc and argv to accept the parameters. I replaced these with "fileArray" and "parameter"... "mf2t" replaces "main" in the native code...
    On the java side the code looks like this:
    static public native boolean mf2t(String s6, String s7);
    public String infile; // Input MIDI file
    public String textOut; // Output text file
    private void MIDIButtonActionPerformed(java.awt.event.ActionEvent evt) {
    Object target=evt.getSource();
    if(target == MIDIButton) {
    if(mf2t(infile,textOut)){
    InfoLabel.setText("MIDI to text conversion complete");
    The code is built on the C side into a DLL using MS Visual Studio.
    On the C side the code looks something like this:
    static char *fileArray[5];
    static int argument=3;
    static char midiArray[25];
    static char txtArray[25];
    void mf2t(int argument,char * fileArray[]);
    // Entry point to native C code is here
    JNIEXPORT jboolean JNICALL
    Java_MainWindow_mf2t (JNIEnv *env, jobject j1, jstring midi, jstring txt)
    const jbyte *midiFile;
    const jbyte *txtFile;
    midiFile=(*env)->GetStringUTFChars(env,midi, NULL);
    txtFile=(*env)->GetStringUTFChars(env,txt, NULL);
    // The lines above just convert the java string into a C equivalent..
    strcpy(midiArray,midiFile);
    strcpy(txtArray,txtFile);
    fileArray[0]="mf2t.exe"; // Here I get fileArray to point to the converted strings
    fileArray[1]=midiArray;
    fileArray[2]=txtArray;
    mf2t(argument,fileArray); // Then I pass this to a native method
    (*env)->ReleaseStringUTFChars(env,midi, midiFile);
    (*env)->ReleaseStringUTFChars(env,txt, txtFile);
    return 1;
    void mf2t(int argument,char * fileArray[]){
    // native code in here
    I think it may have something to do with threads.. I'm not sure though.. It's impossible to know whats going on in the C code when the GUI crashes. If anything looks strange it's because I left out some code here for the sake of brevity... Still if you see anything that stands out let me know..
    Thanks,
    John

  • JNI native threads causing JRE to fail to shut down?

    Hello,
    I am using JNI to communicate with a COM object. I am reasonably certain at this point that my JNI code is handling this properly and the third party COM library is releasing the object in question. We allocate and release hundreds of these objects and we aren't observing any memory leaks. Likewise in our handling of events we receive from the COM object. We attach the thread to Java, deliver the event, and then detach the thread from Java, with very careful error handling around the event delivery to ensure that whatever else happens the detach gets called. This code is very robust and stable in operation and has been working at load in the field for over a year now without any customer problems in the JNI area.
    However, since day one, when I go to shut down the application, the JNI isn't winding down properly. As it happens, since the JRE is running a Tomcat, driven by a wrapper service, the wrapper eventually gives up waiting and shoots the JRE in the head, but the user experience of stopping the wrapper service is ugly and we'd like to clean that up. The JNI code, of course, runs as shared code in the Tomcat.
    It is possible that the third-party library, which does network communications, is keeping a thread pool for use with any of the COM objects even after all COM objects are released. This would be experienced as a one-time hit when the first object is allocated and not as a continual leak, so we'd be unlikely to notice it otherwise.
    Will native non-Java threads running in the JRE but not allocated by the JRE itself cause the JRE to hang on until they've spontaneously decided to clean themselves up? Threads that have never been attached to the JVM? How about threads that were briefly attached to the JVM but then detached? Any worse?
    Ralph

    Hi Ralph,
    I will need some more information regarding this issue.
    1. What platform are you on?
    2. Which JRockit version are you running?
    3. If you remove the wrapper service, does JRockit freeze without exiting properly?
    As a general recommendation I would try to upgrade to the latest JRockit version. It can be downloaded from the OTN http://www.oracle.com/technology/software/products/jrockit/index.html
    You may also try some verbose printouts to debug the issue a little further. Try
    -Xverbose:thread=debug,jni=debug
    This might give us some more insight in what is going on.
    Also when JRockit freezes you can output a Java stack trace using our 'jrcmd' tool which you can find in the same folder as the java executable. Run this tool without any parameters and it will output identifiers (numbers) for every running JRockit instance on your machine. Run the same tool again, this time append the identifier you believe is the one running the Tomcat and add the command 'print_threads', ie
    jrcmd <some_id_here> print_threads
    This may show what JRockit is waiting for.
    Cheers,
    /Henrik

  • Why native code outside the VM when I use JNI in web application?

    I have a web application by using JBOSS as the server in windows XP environment. I need to call native functions in my servletAction class to check some information. After I start JBOSS and WebServer(tomcat), it works well when I launch the web page to call that native funtions in the first a few times, but after a while when I reopen that page in IE to call native funtions it throws me an unexpected error and shut down the jboss automatically. Could know how to solve it? Thank you guys in advance!
    Error message:
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x63BA7AD
    Function=[Unknown.]
    Library=C:\WINDOWS\system32\HaspKeyDAO.dll
    NOTE: We are unable to locate the function name symbol for the error
    just occurred. Please refer to release documentation for possible
    reason and solutions.
    Current Java thread:
         at Key.readBlock(Native Method)     
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
         at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
         at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:113)
         at org.jboss.webservice.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:51)
         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:283)
         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:149)
         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:128)
         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
         at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
         at org.jboss.ejb.Container.invoke(Container.java:854)
         at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:242)
         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
         at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:775)
         at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382)
         at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:324)
         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
         at sun.rmi.transport.Transport$1.run(Transport.java:148)
         at java.security.AccessController.doPrivileged(Native Method)
         at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
         at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
         at java.lang.Thread.run(Thread.java:534)
    Dynamic libraries:
    0x00400000 - 0x0040B000      C:\j2sdk1.4.2_06\bin\java.exe
    0x7C900000 - 0x7C9B0000      C:\WINDOWS\system32\ntdll.dll
    0x7C800000 - 0x7C8F4000      C:\WINDOWS\system32\kernel32.dll
    0x77DD0000 - 0x77E6B000      C:\WINDOWS\system32\ADVAPI32.dll
    0x77E70000 - 0x77F01000      C:\WINDOWS\system32\RPCRT4.dll
    0x77C10000 - 0x77C68000      C:\WINDOWS\system32\MSVCRT.dll
    0x08000000 - 0x08139000      C:\j2sdk1.4.2_06\jre\bin\client\jvm.dll
    0x77D40000 - 0x77DD0000      C:\WINDOWS\system32\USER32.dll
    0x77F10000 - 0x77F56000      C:\WINDOWS\system32\GDI32.dll
    0x76B40000 - 0x76B6D000      C:\WINDOWS\system32\WINMM.dll
    0x10000000 - 0x10007000      C:\j2sdk1.4.2_06\jre\bin\hpi.dll
    0x00390000 - 0x0039E000      C:\j2sdk1.4.2_06\jre\bin\verify.dll
    0x003B0000 - 0x003C9000      C:\j2sdk1.4.2_06\jre\bin\java.dll
    0x003D0000 - 0x003DD000      C:\j2sdk1.4.2_06\jre\bin\zip.dll
    0x003E0000 - 0x003EF000      C:\j2sdk1.4.2_06\jre\bin\net.dll
    0x71AB0000 - 0x71AC7000      C:\WINDOWS\system32\WS2_32.dll
    0x71AA0000 - 0x71AA8000      C:\WINDOWS\system32\WS2HELP.dll
    0x71A50000 - 0x71A8F000      C:\WINDOWS\System32\mswsock.dll
    0x76F20000 - 0x76F47000      C:\WINDOWS\system32\DNSAPI.dll
    0x76FB0000 - 0x76FB8000      C:\WINDOWS\System32\winrnr.dll
    0x76F60000 - 0x76F8C000      C:\WINDOWS\system32\WLDAP32.dll
    0x03070000 - 0x030AC000      C:\Program Files\NewDotNet\newdotnet6_38.dll
    0x774E0000 - 0x7761D000      C:\WINDOWS\system32\ole32.dll
    0x77120000 - 0x771AC000      C:\WINDOWS\system32\OLEAUT32.dll
    0x77260000 - 0x772FE000      C:\WINDOWS\system32\urlmon.dll
    0x77F60000 - 0x77FD6000      C:\WINDOWS\system32\SHLWAPI.dll
    0x77C00000 - 0x77C08000      C:\WINDOWS\system32\VERSION.dll
    0x771B0000 - 0x77256000      C:\WINDOWS\system32\WININET.dll
    0x77A80000 - 0x77B14000      C:\WINDOWS\system32\CRYPT32.dll
    0x77B20000 - 0x77B32000      C:\WINDOWS\system32\MSASN1.dll
    0x77920000 - 0x77A13000      C:\WINDOWS\system32\SETUPAPI.dll
    0x71B20000 - 0x71B32000      C:\WINDOWS\system32\MPR.dll
    0x76C30000 - 0x76C5E000      C:\WINDOWS\system32\WINTRUST.dll
    0x76C90000 - 0x76CB8000      C:\WINDOWS\system32\IMAGEHLP.dll
    0x7C9C0000 - 0x7D1D4000      C:\WINDOWS\system32\SHELL32.dll
    0x773D0000 - 0x774D2000      C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\comctl32.dll
    0x5D090000 - 0x5D127000      C:\WINDOWS\system32\comctl32.dll
    0x76FC0000 - 0x76FC6000      C:\WINDOWS\system32\rasadhlp.dll
    0x662B0000 - 0x66308000      C:\WINDOWS\system32\hnetcfg.dll
    0x71A90000 - 0x71A98000      C:\WINDOWS\System32\wshtcpip.dll
    0x042C0000 - 0x042C6000      C:\j2sdk1.4.2_06\jre\bin\ioser12.dll
    0x04410000 - 0x04418000      C:\j2sdk1.4.2_06\jre\bin\nio.dll
    0x046A0000 - 0x046A5000      C:\j2sdk1.4.2_06\jre\bin\rmi.dll
    0x047F0000 - 0x0490E000      C:\jboss-4.0.0-winsort\server\default\tmp\native\SharedLib\HaspKeyDAO.dll
    0x04A20000 - 0x04A73000      C:\jboss-4.0.0-winsort\server\default\tmp\native\msc\dll\haspms32.dll
    0x06390000 - 0x064AE000      C:\WINDOWS\system32\HaspKeyDAO.dll
    0x76F50000 - 0x76F58000      C:\WINDOWS\system32\wtsapi32.dll
    0x76360000 - 0x76370000      C:\WINDOWS\system32\WINSTA.dll
    0x5B860000 - 0x5B8B4000      C:\WINDOWS\system32\NETAPI32.dll
    0x59A60000 - 0x59B01000      C:\WINDOWS\system32\DBGHELP.dll
    0x76BF0000 - 0x76BFB000      C:\WINDOWS\system32\PSAPI.DLL
    Heap at VM Abort:
    Heap
    def new generation total 9216K, used 2204K [0x10010000, 0x10a00000, 0x12770000)
    eden space 8256K, 26% used [0x10010000, 0x102370e8, 0x10820000)
    from space 960K, 0% used [0x10820000, 0x10820000, 0x10910000)
    to space 960K, 0% used [0x10910000, 0x10910000, 0x10a00000)
    tenured generation total 121024K, used 39043K [0x12770000, 0x19da0000, 0x30010000)
    the space 121024K, 32% used [0x12770000, 0x14d90ec8, 0x14d91000, 0x19da0000)
    compacting perm gen total 23808K, used 23618K [0x30010000, 0x31750000, 0x34010000)
    the space 23808K, 99% used [0x30010000, 0x31720888, 0x31720a00, 0x31750000)
    Local Time = Thu May 26 11:34:39 2005
    Elapsed Time = 3209
    # The exception above was detected in native code outside the VM
    # Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode)
    Following is what I am doing:
    I have a key.java file with several native functions.
    In key.cpp I defined the implementation of above functions then created dynamic link library file key.dll. I put the key.dll to WEB-INF/lib/key.dll.
    Then in a servlet Action class, I called new key().keyPresent and new key().readBlock(0, 8, block, p1,p1).
    Public class Key{
    public native int keyPresent(int password1, int password2);
    public native void readBlock(int startMemoryLocation, int size,
    byte[] block, int password1, int password2);
    static {
    System.loadLibrary("Key");
    //A Singleton Class
    private static Key key;
    private Key()
    public static Key getSingletonObject()
    if ( key== null)
    key = new Key();          
    return key;
    public Object clone()
         throws CloneNotSupportedException
    throw new CloneNotSupportedException();
    Key.cpp:
    #include <jni.h>
    #include "Key.h"
    #include <stdio.h>
    #include "hasp.h"
    #include <memory.h>
    JNIEXPORT jint JNICALL Java_Key_keyPresent
    (JNIEnv *env, jobject obj, jint pass1, jint pass2)
         try{
              int keyPresent = 0;
              int p1, p2, p3, p4;
              int seed = 100;
              int port = 0;
              p1 = p2 = p3 = p4 = 0;
              hasp(LOCALHASP_ISHASP, seed, port, 0, 0, &p1, &p2, &p3, &p4);
              if (p1 == 0) {
                   printf("\nNo Hasp exists. Program aborted.\n");
                   return -1;
              if (p3 == HASPERR_VERSION_MISMATCH) {
              printf("Old driver found - please update driver to actual version.\n");
              return 2;
              hasp(LOCALHASP_HASPSTATUS, seed, port, pass1, pass2, &p1, &p2, &p3, &p4);
              if (p3 == 0) {
                   return 4;
              hasp(LOCALHASP_HASPGENERATION, seed, port, pass1, pass2, &p1, &p2, &p3, &p4);
              if (p3) {
                   printf("Failed: haspKey password is not correct!");
                   return 4;
              } else {
                   switch (p1) {
                   case 0:
                   keyPresent = 3;
                                  break;
                   case 1:
                        keyPresent =1;
                        break;
              return keyPresent;
         }catch(...){
              return -999;
    * READBLOCK
    * reads a block of data from the HASP memory
    JNIEXPORT void JNICALL Java_Key_readBlock
    (JNIEnv *env, jobject obj, jint startMemoryLocation, jint nSize, jbyteArray pBlock, jint pass1, jint pass2)
         try{
              int     p1, p2, p3, p4;
              p1 = (startMemoryLocation+1)/2;
              p2 = nSize >> 1;
              jbyte *javablob = env->GetByteArrayElements(pBlock, 0);
              memset(javablob, 0, nSize);
              p4 = (int)javablob;
              int seed = 100;
              int port = 102;
              hasp(MEMOHASP_READBLOCK, seed, port, pass1, pass2, &p1, &p2, &p3, &p4);
              env->ReleaseByteArrayElements(pBlock, javablob, 0);
              if (p3) {
                   printf("Failed. Error number: %d.\n", p3);
              } else {
         }catch(...){
              printf("readBlock function failed");
    }

    the error happens in your native-code which runs outside the VM of course, since its native.
    You access some memory where you don't have rights to do so, in a normal win32-app you would get the "application crashed at 0xdeadbeef"-window, and since java cannon guarantee that your code did not destroy something it shuts down.
    I would try to debug my code withought java in a C++ IDE/Debugger.
    good luck, lg Clemens

  • IMSL C library causes JVM crash through JNI in GC with JDK 1.6

    Hi Java friends,
    We use the IMSL C library (made by Visual Numerics) via JNI which picks up a C++ so on Linux. Under JDK 1.5 it works fine. Under 1.6 it crashes in the GC. I put together a very simple testcase that just calls the IMSL error options function (which sets up the library) and it causes the JVM to crash somewhere in the GC. The reason I know it's in the GC is that the crash is not immediate, it's only when the GC is active, so we wrote some test code to push the GC like this:
    log("Looping");
    long block = 10000000;
    int numBlocks = 10;
    long loops = block * numBlocks;
    for (long i = 0; i < loops; i++) {
    // Create some objects that need disposal
    String.valueOf(i);
    if (i % block == 0) {
    log("Reached " + i);
    System.gc();
    Anyone got any idea why? Crash dump follows.
    Many thanks,
    David.
    # An unexpected error has been detected by Java Runtime Environment:
    # SIGSEGV (0xb) at pc=0x00000000, pid=23854, tid=4143893424
    # Java VM: Java HotSpot(TM) Server VM (1.6.0_03-b05 mixed mode)
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    --------------- T H R E A D ---------------
    Current thread (0x08058c00): JavaThread "main" [_thread_in_Java, id=23855]
    siginfo:
    [error occurred during error reporting, step 90, id 0xb]
    Stack: [0xf6f9c000,0xf6fed000), sp=0xf6feb55c, free space=317k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    V [libjvm.so+0x53b9a7]
    V [libjvm.so+0x53c5b4]
    C [libpthread.so.0+0xb890]
    V [libjvm.so+0x53b3f5]
    V [libjvm.so+0x53b9a7]
    V [libjvm.so+0x4541d0]
    V [libjvm.so+0x451a68]
    --------------- P R O C E S S ---------------
    Java Threads: ( => current thread )
    0x08157c00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=23866]
    0x08155c00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=23865]
    0x08154800 JavaThread "CompilerThread0" daemon [_thread_blocked, id=23864]
    0x08153400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=23863]
    0x08140400 JavaThread "Finalizer" daemon [_thread_blocked, id=23862]
    0x0813f800 JavaThread "Reference Handler" daemon [_thread_blocked, id=23861]
    =>0x08058c00 JavaThread "main" [_thread_in_Java, id=23855]
    Other Threads:
    0x0813d000 VMThread [id=23860]
    0x08159400 WatcherThread [id=23867]
    VM state:synchronizing (normal execution)
    VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
    [0x08056d60/0x08056d88] Safepoint_lock - owner thread: 0x0813d000
    [0x08056de0/0x08056e08] Threads_lock - owner thread: 0x0813d000
    Heap
    PSYoungGen total 87040K, used 8962K [0xecca0000, 0xf21e0000, 0xf3e60000)
    eden space 86784K, 10% used [0xecca0000,0xed528b98,0xf2160000)
    from space 256K, 87% used [0xf21a0000,0xf21d8040,0xf21e0000)
    to space 256K, 0% used [0xf2160000,0xf2160000,0xf21a0000)
    PSOldGen total 230976K, used 0K [0xb3e60000, 0xc1ff0000, 0xecca0000)
    object space 230976K, 0% used [0xb3e60000,0xb3e60000,0xc1ff0000)
    PSPermGen total 16384K, used 2540K [0xafe60000, 0xb0e60000, 0xb3e60000)
    object space 16384K, 15% used [0xafe60000,0xb00db1d8,0xb0e60000)
    Dynamic libraries:
    0085a000-0086f000 r-xp 00000000 68:06 213117 /lib/ld-2.3.4.so
    0086f000-00870000 r-xp 00015000 68:06 213117 /lib/ld-2.3.4.so
    00870000-00871000 rwxp 00016000 68:06 213117 /lib/ld-2.3.4.so
    00873000-00875000 r-xp 00000000 68:06 213179 /lib/libdl-2.3.4.so
    00875000-00877000 rwxp 00001000 68:06 213179 /lib/libdl-2.3.4.so
    0089b000-009c0000 r-xp 00000000 68:06 213118 /lib/tls/libc-2.3.4.so
    009c0000-009c1000 r-xp 00124000 68:06 213118 /lib/tls/libc-2.3.4.so
    009c1000-009c4000 rwxp 00125000 68:06 213118 /lib/tls/libc-2.3.4.so
    009c4000-009c6000 rwxp 009c4000 00:00 0
    009c8000-009e9000 r-xp 00000000 68:06 213200 /lib/tls/libm-2.3.4.so
    009e9000-009eb000 rwxp 00020000 68:06 213200 /lib/tls/libm-2.3.4.so
    009ed000-009fb000 r-xp 00000000 68:06 213087 /lib/tls/libpthread-2.3.4.so
    009fb000-009fd000 rwxp 0000d000 68:06 213087 /lib/tls/libpthread-2.3.4.so
    009fd000-009ff000 rwxp 009fd000 00:00 0
    00a01000-00a09000 r-xp 00000000 68:06 213205 /lib/tls/librt-2.3.4.so
    00a09000-00a0b000 rwxp 00007000 68:06 213205 /lib/tls/librt-2.3.4.so
    00a0b000-00a15000 rwxp 00a0b000 00:00 0
    00a31000-00a43000 r-xp 00000000 68:06 213202 /lib/libnsl-2.3.4.so
    00a43000-00a45000 rwxp 00011000 68:06 213202 /lib/libnsl-2.3.4.so
    00a45000-00a47000 rwxp 00a45000 00:00 0
    06000000-065a0000 r-xp 00000000 00:1c 172281 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
    065a0000-065db000 rwxp 005a0000 00:1c 172281 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server/libjvm.so
    065db000-069fc000 rwxp 065db000 00:00 0
    08048000-08052000 r-xp 00000000 00:1c 287782 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin/java
    08052000-08053000 rwxp 00009000 00:1c 287782 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin/java
    08053000-08545000 rwxp 08053000 00:00 0
    a7210000-a7211000 ---p a7210000 00:00 0
    a7211000-a7c11000 rwxp a7211000 00:00 0
    a7c11000-a7cd7000 r-xp 00000000 00:1c 498129 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libstdc++.so.6.0.3
    a7cd7000-a7cdc000 rwxp 000c6000 00:1c 498129 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libstdc++.so.6.0.3
    a7cdc000-a7ce1000 rwxp a7cdc000 00:00 0
    a7ce1000-a7dc6000 r-xp 00000000 00:1f 2900632 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libstlport-mcg-5.1.so
    a7dc6000-a7de2000 rwxp 000e4000 00:1f 2900632 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libstlport-mcg-5.1.so
    a7de2000-a7de6000 rwxp a7de2000 00:00 0
    a7de6000-a7f5c000 r-xp 00000000 00:1f 2900652 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_vml_def.so
    a7f5c000-a7f6b000 rwxp 00175000 00:1f 2900652 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_vml_def.so
    a7f6b000-a8434000 r-xp 00000000 00:1f 2900523 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_lapack.so
    a8434000-a8436000 rwxp 004c9000 00:1f 2900523 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_lapack.so
    a8436000-a8492000 r-xp 00000000 00:1f 2900484 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_core.so
    a8492000-a8496000 rwxp 0005b000 00:1f 2900484 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_core.so
    a8496000-a84a4000 rwxp a8496000 00:00 0
    a84a4000-a8652000 r-xp 00000000 00:1f 2900521 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel_thread.so
    a8652000-a869f000 rwxp 001ae000 00:1f 2900521 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel_thread.so
    a869f000-a86a0000 rwxp a869f000 00:00 0
    a86a0000-a87d9000 r-xp 00000000 00:1f 2900517 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel.so
    a87d9000-a87dc000 rwxp 00139000 00:1f 2900517 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libmkl_intel.so
    a87dc000-a87e2000 rwxp a87dc000 00:00 0
    a87e2000-a87e9000 r-xp 00000000 00:1f 570263 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat_iblas.so
    a87e9000-a87ea000 rwxp 00006000 00:1f 570263 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat_iblas.so
    a87ea000-a8b08000 r-xp 00000000 00:1f 570239 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat.so
    a8b08000-a8b45000 rwxp 0031d000 00:1f 570239 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcstat.so
    a8b45000-a8b5e000 r-xp 00000000 00:1f 570822 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_iblas.so
    a8b5e000-a8b5f000 rwxp 00019000 00:1f 570822 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_iblas.so
    a8b5f000-a8c18000 r-xp 00000000 00:1f 570832 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_scalar.so
    a8c18000-a8c19000 rwxp 000b8000 00:1f 570832 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath_scalar.so
    a8c19000-a8ee7000 r-xp 00000000 00:1f 570819 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath.so
    a8ee7000-a8ef6000 rwxp 002ce000 00:1f 570819 /home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib/libimslcmath.so
    a8ef6000-a8ef7000 rwxp a8ef6000 00:00 0
    a8ef7000-a8f19000 r-xp 00000000 00:1f 2900421 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libboost_thread-mcg-1.34-stlport-5.1.so
    a8f19000-a8f1d000 rwxp 00022000 00:1f 2900421 /home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib/libboost_thread-mcg-1.34-stlport-5.1.so
    a8f1d000-aa180000 r-xp 00000000 00:1f 761178 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2mlclib.so
    aa180000-aa430000 rwxp 01263000 00:1f 761178 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2mlclib.so
    aa430000-aa53a000 rwxp aa430000 00:00 0
    aa53a000-ad779000 r-xp 00000000 00:1f 699688 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2ocean.so
    ad779000-ae56b000 rwxp 0323f000 00:1f 699688 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2ocean.so
    ae56b000-ae7a8000 rwxp ae56b000 00:00 0
    ae7a8000-ae886000 r-xp 00000000 00:1f 699721 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2generic.so
    ae886000-ae8a6000 rwxp 000de000 00:1f 699721 /home/cartedav/workspaces/dev/mlclib/build/i686-rhel4.0-gcc3.4/checked-stlport-fine-full-multi-dynamic/libgda2generic.so
    ae8a6000-ae8ac000 rwxp ae8a6000 00:00 0
    ae8ac000-ae904000 r-xp 00000000 00:1c 206109 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libguide.so
    ae904000-ae909000 rwxp 00058000 00:1c 206109 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libguide.so
    ae909000-ae90e000 rwxp ae909000 00:00 0
    ae90e000-aef20000 r-xp 00000000 00:1c 52046 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2rt.so
    aef20000-af01d000 rwxp 00612000 00:1c 52046 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2rt.so
    af01d000-af028000 rwxp af01d000 00:00 0
    af028000-af030000 r-xp 00000000 00:1c 497827 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libgcc_s.so.1
    af030000-af031000 rwxp 00007000 00:1c 497827 /home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib/libgcc_s.so.1
    af031000-af136000 r-xp 00000000 00:1c 205704 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2jni.so
    af136000-af158000 rwxp 00105000 00:1c 205704 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/libgda2jni.so
    af158000-af15d000 rwxp af158000 00:00 0
    af15d000-af15f000 r-xs 00009000 00:1c 205693 /home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/gda2.jar
    af15f000-af160000 ---p af15f000 00:00 0
    af160000-af1e0000 rwxp af160000 00:00 0
    af1e0000-af1e3000 ---p af1e0000 00:00 0
    af1e3000-af231000 rwxp af1e3000 00:00 0
    af231000-af234000 ---p af231000 00:00 0
    af234000-af2b2000 rwxp af234000 00:00 0
    af2b2000-af2b5000 ---p af2b2000 00:00 0
    af2b5000-af333000 rwxp af2b5000 00:00 0
    af333000-af336000 ---p af333000 00:00 0
    af336000-af384000 rwxp af336000 00:00 0
    af384000-af584000 r-xp 00000000 68:06 101636 /usr/lib/locale/locale-archive
    af584000-af587000 ---p af584000 00:00 0
    af587000-af5d5000 rwxp af587000 00:00 0
    af5d5000-af5d8000 ---p af5d5000 00:00 0
    af5d8000-af626000 rwxp af5d8000 00:00 0
    af626000-af627000 ---p af626000 00:00 0
    af627000-af6d7000 rwxp af627000 00:00 0
    af6d7000-af853000 r-xs 02c8f000 00:1c 925583 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/rt.jar
    af853000-af854000 ---p af853000 00:00 0
    af854000-af8d4000 rwxp af854000 00:00 0
    af8d4000-af8d5000 ---p af8d4000 00:00 0
    af8d5000-af955000 rwxp af8d5000 00:00 0
    af955000-af956000 ---p af955000 00:00 0
    af956000-af9d6000 rwxp af956000 00:00 0
    af9d6000-af9d7000 ---p af9d6000 00:00 0
    af9d7000-afa5f000 rwxp af9d7000 00:00 0
    afa5f000-afa77000 rwxp afa5f000 00:00 0
    afa77000-afae8000 rwxp afa77000 00:00 0
    afae8000-afc3f000 rwxp afae8000 00:00 0
    afc3f000-afc47000 rwxp afc3f000 00:00 0
    afc47000-afc5f000 rwxp afc47000 00:00 0
    afc5f000-afcd0000 rwxp afc5f000 00:00 0
    afcd0000-afe26000 rwxp afcd0000 00:00 0
    afe26000-afe51000 rwxp afe26000 00:00 0
    afe51000-afe5f000 rwxp afe51000 00:00 0
    afe5f000-b0e60000 rwxp afe5f000 00:00 0
    b0e60000-b3e60000 rwxp b0e60000 00:00 0
    b3e60000-c1ff0000 rwxp b3e60000 00:00 0
    c1ff0000-ecca0000 rwxp c1ff0000 00:00 0
    ecca0000-f21e0000 rwxp ecca0000 00:00 0
    f21e0000-f3e60000 rwxp f21e0000 00:00 0
    f3e6d000-f3e76000 rwxp f3e6d000 00:00 0
    f3e76000-f3f2d000 rwxp f3e76000 00:00 0
    f3f2d000-f416d000 rwxp f3f2d000 00:00 0
    f416d000-f6f2d000 rwxp f416d000 00:00 0
    f6f2d000-f6f3c000 r-xp 00000000 00:1c 172554 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libzip.so
    f6f3c000-f6f3e000 rwxp 0000e000 00:1c 172554 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libzip.so
    f6f3e000-f6f61000 r-xp 00000000 00:1c 172497 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libjava.so
    f6f61000-f6f63000 rwxp 00023000 00:1c 172497 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libjava.so
    f6f63000-f6f6e000 r-xp 00000000 00:1c 172493 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libverify.so
    f6f6e000-f6f6f000 rwxp 0000b000 00:1c 172493 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/libverify.so
    f6f6f000-f6f77000 rwxs 00000000 68:06 247809 /tmp/hsperfdata_cartedav/23854
    f6f77000-f6f7f000 r-xp 00000000 68:06 213047 /lib/libnss_nis-2.3.4.so
    f6f7f000-f6f81000 rwxp 00007000 68:06 213047 /lib/libnss_nis-2.3.4.so
    f6f81000-f6f8a000 r-xp 00000000 68:06 213042 /lib/libnss_files-2.3.4.so
    f6f8a000-f6f8c000 rwxp 00008000 68:06 213042 /lib/libnss_files-2.3.4.so
    f6f93000-f6f99000 r-xp 00000000 00:1c 172254 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
    f6f99000-f6f9a000 rwxp 00006000 00:1c 172254 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/native_threads/libhpi.so
    f6f9a000-f6f9b000 rwxp f6f9a000 00:00 0
    f6f9b000-f6f9c000 ---p f6f9b000 00:00 0
    f6f9c000-f6f9f000 ---p f6f9c000 00:00 0
    f6f9f000-f6fef000 rwxp f6f9f000 00:00 0
    f6fef000-f6ff6000 r-xp 00000000 00:1c 172514 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
    f6ff6000-f6ff8000 rwxp 00006000 00:1c 172514 /home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/jli/libjli.so
    f6fff000-f7000000 rwxp f6fff000 00:00 0
    feff9000-ff000000 rwxp feff9000 00:00 0
    ffffe000-fffff000 ---p 00000000 00:00 0
    VM Arguments:
    java_command: TestCrash AGRCRV.ODR.CC.xdr
    Launcher Type: SUN_STANDARD
    Environment Variables:
    JAVA_HOME=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03
    PATH=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/bin:/home/cartedav/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/bin:/home/gdadev/tools/i686/rhel4.0/bin:/home/cartedav/workspaces/dev/images/i686-rhel4.0-gcc3.4/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/bin:/home/gdadev/tools/i686/rhel4.0/j2sdk/bin:/apps/linuxdev/bin:/usr/kerberos/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/quest/bin:/usr/X11R6/bin:
    LD_LIBRARY_PATH=/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386/server:/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/lib/i386:/home/gdadev/tools/i686/rhel4.0/jdk1.6.0_03/jre/../lib/i386:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib:/home/gdadev/builds/nightly/i686-rhel4.0-gcc3.4/:/home/cartedav/workspaces/dev/mlclib/vendors-gda2/i686-rhel4.0-gcc3.4/lib:/home/gdadev/tools/i686/rhel4.0/j2sdk/lib:/home/gdadev/tools/i686/rhel4.0/gcc-3.4.6/lib:/home/gdadev/tools/i686/rhel4.0/lib:/home/cartedav/workspaces/dev/images/i686-rhel4.0-gcc3.4/lib:/home/cartedav/workspaces/dev/vendor/i686-rhel4.0-gcc3.4/lib:/home/gdadev/tools/i686/rhel4.0/j2sdk/lib:/apps/linuxdev/lib::
    SHELL=/bin/csh
    DISPLAY=169.243.119.66:0.0
    HOSTTYPE=i386-linux
    OSTYPE=linux
    MACHTYPE=i386
    Signal Handlers:
    SIGSEGV: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGBUS: [libjvm.so+0x53c560], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGFPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGPIPE: [libjvm.so+0x451a50], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGILL: [libjvm.so+0x451a50], sa_mask[0]=0x00000000, sa_flags=0xe0000000, flags was changed from 0x10000004, consider using jsig library
    SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
    SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
    SIGHUP: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGINT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGQUIT: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGTERM: [libjvm.so+0x4534a0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
    SIGUSR2: [libjvm.so+0x453a80], sa_mask[0]=0x00000000, sa_flags=0x10000004
    --------------- S Y S T E M ---------------
    OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
    uname:Linux 2.6.9-42.0.2.ELhugemem #1 SMP Thu Aug 17 18:22:52 EDT 2006 i686
    libc:glibc 2.3.4 NPTL 2.3.4
    rlimit: STACK 10240k, CORE 0k, NPROC 274431, NOFILE 1024, AS infinity
    load average:0.28 0.17 0.16
    CPU:total 4 (2 cores per cpu, 1 threads per core) family 15 model 65 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnow, 3dnowext
    Memory: 4k page, physical 16629672k(722080k free), swap 16779884k(16779740k free)
    vm_info: Java HotSpot(TM) Server VM (1.6.0_03-b05) for linux-x86, built on Sep 24 2007 22:32:39 by "java_re" with gcc 3.2.1-7a (J2SE release)

    Thanks very much for your advice. Unfortunately, stepping through the code doesn't help at all. The error occurs much later after the C code has been executed, whilst running the java code (which is just creating string objects to invoke the GC). The C code that we are executing is extremely simple - it consists of Sun's JNI example coupled with a sinlge call to the IMSL error options function:
    JNIEXPORT jbyteArray JNICALL Java_ReadFile_loadFile
    (JNIEnv * env, jobject jobj, jstring name) {
    printf("%s", "Setting imsl_error_options()...\n");
    imsl_error_options( IMSL_SET_SIGNAL_TRAPPING, 0, // Disable IMSL signal trapping - necessary for MT code.
    IMSL_SET_STOP, IMSL_FATAL, 0, // Disable stopping on FATAL errors
    IMSL_SET_STOP, IMSL_FATAL_IMMEDIATE, 0, // Disable stopping on FATAL_IMMEDIATE errors
    IMSL_SET_STOP, IMSL_TERMINAL, 0, // Disable stopping on TERMINAL errors
    IMSL_SET_PRINT, IMSL_FATAL, 1, // Enable printing on FATAL errors
    IMSL_SET_PRINT, IMSL_FATAL_IMMEDIATE, 1, // Enable printing on FATAL_IMMEDIATE errors
    IMSL_SET_PRINT, IMSL_TERMINAL, 1, // Enable printing on TERMINAL errors
    IMSL_SET_PRINT, IMSL_WARNING, 1, // Enable printing on WARNING errors
    IMSL_SET_PRINT, IMSL_WARNING_IMMEDIATE, 1, // Enable printing on WARNING_IMMEDIATE errors
    IMSL_SET_PRINT, IMSL_ALERT, 1, // Enable printing on TERMINAL errors
    IMSL_SET_PRINT, IMSL_NOTE, 1, // Enable printing on TERMINAL errors
    0 );
    caddr_t m;
    jbyteArray jb;
    jboolean iscopy;
    struct stat finfo;
    const char mfile = (env)->GetStringUTFChars(
    env, name, &iscopy);
    int fd = open(mfile, O_RDONLY);
    if (fd == -1) {
    printf("Could not open %s\n", mfile);
    lstat(mfile, &finfo);
    m = mmap((caddr_t) 0, finfo.st_size,
    PROT_READ, MAP_PRIVATE, fd, 0);
    if (m == (caddr_t)-1) {
    printf("Could not mmap %s\n", mfile);
    return(0);
    jb=(*env)->NewByteArray(env, finfo.st_size);
    (*env)->SetByteArrayRegion(env, jb, 0,
    finfo.st_size, (jbyte *)m);
    close(fd);
    (*env)->ReleaseStringUTFChars(env, name, mfile);
    return (jb);
    If I remove the call to imsl_error_options then there is no adverse behaviour - the Java loop completes ok (creating 1 trillion strings in the process) and the manual call the GC works fine. With the call to imsl, the execution gets to the string creation loop (in Java, after the C has been executed) and then it dies pretty quickly (presumably after the GC kicks in to clean up some of the strings).
    Here is the java code:
    import java.util.*;
    class ReadFile {
    //Native method declaration
    native byte[] loadFile(String name);
    //Load the library
    static {
    System.loadLibrary("nativelib");
    public static void main(String args[]) {
    byte buf[];
    //Create class instance
    ReadFile mappedFile=new ReadFile();
    //Call native method to load ReadFile.java
    buf=mappedFile.loadFile("ReadFile.java");
    //Print contents of ReadFile.java
    for(int i=0;i<buf.length;i++) {
    System.out.print((char)buf);
    System.out.print("Now running the string creation loop...\n");
    long block = 100000000;
    int numBlocks = 10;
    long loops = block * numBlocks;
    for (long i = 0; i < loops; i++) {
    // Create some objects that need disposal
    String.valueOf(i);
    if (i % block == 0) {
    System.out.print("Reached " + i + "\n");
    System.out.print("Now running the GC...\n");
    System.gc();

  • JVM Crash When Using JNI and COM

    I'm trying to call a DLL compiled from VB6 source code that I do not have access to. The VB6 code simply retrieves data from a DB2 database using ADO and my client code grabs that data and marshals it to my Java code. I'm attempting to achieve this using JNI and COM (without a third-party bridge). It works 75% of the time, but the other 25% of the time, the JVM crashes with the usual Hotspot crash log containing an access violation exception. However, I don't know what in my C++ code (VC++ 8) could be causing this except for passing a "wild" pointer to the code lying underneath the COM object interface. If that is the case, I don't know how I am doing that.
    The Java code that is calling my native method is running on Tomcat 5.5.25 and just to be safe, I am not allowing multiple threads to concurrently call the method in my JNI DLL (though I realize that this will kill performance). Once I can get past this problem, I'll do the COM interfacing on a worker thread in my native code so I don't screw up CoInitialize and CoUninitialize calls in the case the same thread is concurrently executing multiple calls to my native code.
    I've noticed that in most cases, the JVM crashes during my call to the pClsAccount->OpenConnection method. However, my DLL isn't what is listed on the top of the call stack, which is why I suspect the passing of a wild pointer, though I'm just taking a guess at that. Does anyone have an idea as to what's going on ?
    JNIEXPORT jobject JNICALL Java_CustomerInfo_nGetCustomerAccountInfo(JNIEnv *env, jobject customerInfo, jstring accountNumber, jstring iniFileName)
    jboolean isCopy;
    // Account info class and instance to be instantiated
    jclass accountInfoCls = NULL;
    jobject accountInfoObj = NULL;
    // The constructor ID of the accountInfoCls
    jmethodID ctorID = NULL;
    // Pointer to the interface for the ClsAccount COM object
    _clsAccount *pClsAccount = NULL;
    HRESULT hr;
    BSTR bstrIniFileName(L"");
    try
    const char *nativeAccountNumber = NULL;
    if (accountNumber != NULL)
    nativeAccountNumber = env->GetStringUTFChars(accountNumber, &isCopy);
    else
    jclass newExcCls;
    env->ExceptionDescribe();
    env->ExceptionClear();
    newExcCls = env->FindClass("java/lang/IllegalArgumentException");
    env->ThrowNew(newExcCls, "accountNumber passed in was null !");
    return NULL;
    // Initialization
    variantt varConnectionSucceeded = variantt(false);
    variantt varGetAccountInfoSucceeded = variantt(false);
    variantt varAccountNumber = variantt(nativeAccountNumber);
    bstrt bstrLastPaymentDate = bstrt();
    bstrt bstrLastErrorMessage = bstrt();
    bstrt bstrLastErrorNumber = bstrt();
    jlong jTotalDue = NULL;
    jlong jEstablishedDueDay = NULL;
    jlong jLastPaymentAmount = NULL;
    jstring jLastPaymentDate = NULL;
    jstring jLastErrorMessage = NULL;
    jstring jLastErrorNumber = NULL;
    jthrowable jException = NULL;
    const char *chLastPaymentDate = NULL;
    const char *chLastErrorMessage = NULL;
    const char *chLastErrorNumber = NULL;
    long long totalDue;
    long long lastPaymentAmount;
    long establishedDueDateDay;
    //Convert string from Java string to C string to VB string
    const char *nativeIniFileName = NULL;
    if (iniFileName != NULL)
    nativeIniFileName = env->GetStringUTFChars(iniFileName, &isCopy);
    else
    jclass newExcCls;
    env->ExceptionDescribe();
    env->ExceptionClear();
    newExcCls = env->FindClass("java/lang/IllegalArgumentException");
    env->ThrowNew(newExcCls, "iniFileName passed in was null");
    return NULL;
    bstrIniFileName = comutil::ConvertStringToBSTR(nativeIniFileName);
    CoInitialize(NULL);
    // Create an instance of the COClass with the interface over it
    hr = CoCreateInstance(__uuidof(clsAccount), NULL, CLSCTX_INPROC_SERVER, __uuidof(_clsAccount), (void **)&pClsAccount);
    if (hr == S_OK)
    varConnectionSucceeded.boolVal = pClsAccount->OpenConnection(&bstrIniFileName);
    &#12288;
    if (varConnectionSucceeded.boolVal == -1)
    varGetAccountInfoSucceeded.boolVal = pClsAccount->GetAccountPaymentInformation(&(varAccountNumber.GetVARIANT()));
    env->ReleaseStringUTFChars(accountNumber, nativeAccountNumber);
    // Extract all available account information from the ClsAccount object
    if (varGetAccountInfoSucceeded.boolVal == -1)
    totalDue = pClsAccount->TotalDue.int64;
    establishedDueDateDay = pClsAccount->EstablishedDueDateDay;
    lastPaymentAmount = pClsAccount->LastPaymentAmount.int64;
    bstrLastPaymentDate = pClsAccount->LastPaymentDate;
    chLastPaymentDate = comutil::ConvertBSTRToString(bstrLastPaymentDate.GetBSTR());
    jTotalDue = (jlong)totalDue;
    jEstablishedDueDay = (jlong)establishedDueDateDay;
    jLastPaymentAmount = (jlong)lastPaymentAmount;
    jLastPaymentDate = env->NewStringUTF(chLastPaymentDate);
    delete[] chLastPaymentDate;
    pClsAccount->CloseConnection();
    // Populate error fields if any errors occur
    bstrLastErrorMessage = pClsAccount->LastErrMessage;
    chLastErrorMessage = comutil::ConvertBSTRToString(bstrLastErrorMessage.GetBSTR());
    bstrLastErrorNumber = pClsAccount->LastErrNumber;
    chLastErrorNumber = comutil::ConvertBSTRToString(bstrLastErrorNumber.GetBSTR());
    jLastErrorMessage = env->NewStringUTF(chLastErrorMessage);
    jLastErrorNumber = env->NewStringUTF(chLastErrorNumber);
    delete[] chLastErrorMessage;
    delete[] chLastErrorNumber;
    const char* clsName = "com/nuance/merchantsmutual/businessentities/CustomerAccountInfo";
    // Find the Java class and the ID of its constructor
    accountInfoCls = env->FindClass(clsName);
    ctorID = env->GetMethodID(accountInfoCls, "<init>", "(JJJLjava/lang/String;Ljava/lang/String;Ljava/lang/String;)V");
    jException = env->ExceptionOccurred();
    if (jException != NULL)
    env->ExceptionDescribe();
    env->ExceptionClear();
    //Release all resources associated with the ClsAccount instance
    pClsAccount->Release();
    //Instantiate the class with the given parameters
    accountInfoObj = env->NewObject(accountInfoCls, ctorID, jTotalDue, jEstablishedDueDay, jLastPaymentAmount, jLastPaymentDate, jLastErrorMessage, jLastErrorNumber);
    jException = env->ExceptionOccurred();
    if (jException != NULL)
    env->ExceptionDescribe();
    env->ExceptionClear();
    else if (hr == REGDB_E_CLASSNOTREG)
    cout << "COM class not registered" << endl;
    else if ( hr == CLASS_E_NOAGGREGATION)
    cout << "COM class can't be aggregated" << endl;
    else if (hr == E_NOINTERFACE)
    cout << "No interface for COM class clsAccount" << endl;
    else if (hr == E_POINTER)
    cout << "*ppv pointer was NULL !" << endl;
    else
    cout << "Error occurred while creating COM object. HR is [" << hr << "]" << endl;
    // Free the BSTR because a new one was returned with a call to comutil::ConvertStringToBSTR
    SysFreeString(bstrIniFileName);
    // Release the string when it's no longer needed. MUST call if string won't be used
    // anymore or else a memory leak will occur
    env->ReleaseStringUTFChars(iniFileName, nativeIniFileName);
    CoUninitialize();
    &#12288;
    catch (_com_error &e)
    cout << "Encountered an exception in GetCustomerAccountInfo: Error was " << e.ErrorMessage();
    pClsAccount->Release();
    catch (...)
    pClsAccount->Release();
    return accountInfoObj;
    Edited by: Cthulhu76 on Jan 5, 2010 9:18 AM

    0x49202400 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=5340, stack(0x49bf0000,0x49c40000)]
    0x48a7e800 JavaThread "Thread-1" [_thread_in_native, id=5976, stack(0x48f00000,0x48f50000)]
    0x48a0dc00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3072, stack(0x48c60000,0x48cb0000)]
    0x48a09000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=4988, stack(0x48c10000,0x48c60000)]
    0x48a07c00 JavaThread "Attach Listener" daemon [_thread_blocked, id=3124, stack(0x48bc0000,0x48c10000)]
    0x48a07000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2572, stack(0x48b70000,0x48bc0000)]
    0x489f5c00 JavaThread "Finalizer" daemon [_thread_blocked, id=5752, stack(0x48b20000,0x48b70000)]
    0x489f4c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=2596, stack(0x48ad0000,0x48b20000)]
    0x003c6000 JavaThread "main" [_thread_in_native, id=4252, stack(0x00820000,0x00870000)]
    Other Threads:
    0x489f0400 VMThread [stack: 0x48a80000,0x48ad0000] [id=5624]
    0x48a18800 WatcherThread [stack: 0x48cb0000,0x48d00000] [id=1192]
    VM state:not at safepoint (normal execution)
    VM Mutex/Monitor currently owned by a thread: None
    Heap
    def new generation total 36288K, used 12762K [0x02940000, 0x050a0000, 0x07800000)
    eden space 32256K, 34% used [0x02940000, 0x0343af58, 0x048c0000)
    from space 4032K, 37% used [0x04cb0000, 0x04e2ba28, 0x050a0000)
    to space 4032K, 0% used [0x048c0000, 0x048c0000, 0x04cb0000)
    tenured generation total 483968K, used 7518K [0x07800000, 0x250a0000, 0x42940000)
    the space 483968K, 1% used [0x07800000, 0x07f57958, 0x07f57a00, 0x250a0000)
    compacting perm gen total 14080K, used 14016K [0x42940000, 0x43700000, 0x46940000)
    the space 14080K, 99% used [0x42940000, 0x436f0320, 0x436f0400, 0x43700000)
    No shared spaces configured.
    Dynamic libraries:
    0x00400000 - 0x0040f000      C:\Program Files\Apache Software Foundation\Tomcat 5.5\bin\tomcat5.exe
    0x7c800000 - 0x7c8c0000      C:\WINDOWS\system32\ntdll.dll
    0x77e40000 - 0x77f42000      C:\WINDOWS\system32\kernel32.dll
    0x77380000 - 0x77411000      C:\WINDOWS\system32\USER32.dll
    0x77c00000 - 0x77c48000      C:\WINDOWS\system32\GDI32.dll
    0x77f50000 - 0x77feb000      C:\WINDOWS\system32\ADVAPI32.dll
    0x77c50000 - 0x77cef000      C:\WINDOWS\system32\RPCRT4.dll
    0x76f50000 - 0x76f63000      C:\WINDOWS\system32\Secur32.dll
    0x77ba0000 - 0x77bfa000      C:\WINDOWS\system32\MSVCRT.dll
    0x7c8d0000 - 0x7d0cf000      C:\WINDOWS\system32\SHELL32.dll
    0x77da0000 - 0x77df2000      C:\WINDOWS\system32\SHLWAPI.dll
    0x76290000 - 0x762ad000      C:\WINDOWS\system32\IMM32.DLL
    0x77420000 - 0x77523000      C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_D8713E55\comctl32.dll
    0x6d7c0000 - 0x6da10000      C:\Program Files\Java\jre1.6.0_07\bin\client\jvm.dll
    0x76aa0000 - 0x76acd000      C:\WINDOWS\system32\WINMM.dll
    0x7c340000 - 0x7c396000      C:\WINDOWS\system32\MSVCR71.dll
    0x6d270000 - 0x6d278000      C:\Program Files\Java\jre1.6.0_07\bin\hpi.dll
    0x76b70000 - 0x76b7b000      C:\WINDOWS\system32\PSAPI.DLL
    0x6d770000 - 0x6d77c000      C:\Program Files\Java\jre1.6.0_07\bin\verify.dll
    0x6d310000 - 0x6d32f000      C:\Program Files\Java\jre1.6.0_07\bin\java.dll
    0x6d7b0000 - 0x6d7bf000      C:\Program Files\Java\jre1.6.0_07\bin\zip.dll
    0x6d570000 - 0x6d583000      C:\Program Files\Java\jre1.6.0_07\bin\net.dll
    0x71c00000 - 0x71c17000      C:\WINDOWS\system32\WS2_32.dll
    0x71bf0000 - 0x71bf8000      C:\WINDOWS\system32\WS2HELP.dll
    0x71b20000 - 0x71b61000      C:\WINDOWS\system32\mswsock.dll
    0x5f270000 - 0x5f2ca000      C:\WINDOWS\system32\hnetcfg.dll
    0x71ae0000 - 0x71ae8000      C:\WINDOWS\System32\wshtcpip.dll
    0x76ed0000 - 0x76efa000      C:\WINDOWS\system32\DNSAPI.dll
    0x76f70000 - 0x76f77000      C:\WINDOWS\System32\winrnr.dll
    0x76f10000 - 0x76f3e000      C:\WINDOWS\system32\WLDAP32.dll
    0x76f80000 - 0x76f85000      C:\WINDOWS\system32\rasadhlp.dll
    0x4a6a0000 - 0x4a6ac000      C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\CustomerInfoProxy.dll
    0x77670000 - 0x777a9000      C:\WINDOWS\system32\ole32.dll
    0x77d00000 - 0x77d8b000      C:\WINDOWS\system32\OLEAUT32.dll
    0x7c420000 - 0x7c4a7000      C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_E6967989\MSVCP80.dll
    0x78130000 - 0x781cb000      C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_E6967989\MSVCR80.dll
    0x777b0000 - 0x77833000      C:\WINDOWS\system32\CLBCatQ.DLL
    0x77010000 - 0x770d6000      C:\WINDOWS\system32\COMRes.dll
    0x77b90000 - 0x77b98000      C:\WINDOWS\system32\VERSION.dll
    0x75da0000 - 0x75e5d000      C:\WINDOWS\system32\SXS.DLL
    0x75e60000 - 0x75e87000      C:\WINDOWS\system32\apphelp.dll
    0x4dc30000 - 0x4dc5e000      C:\WINDOWS\system32\msctfime.ime
    0x4b0d0000 - 0x4b395000      C:\WINDOWS\system32\xpsp2res.dll
    0x71bb0000 - 0x71bb9000      C:\WINDOWS\system32\WSOCK32.dll
    0x4bbe0000 - 0x4bbea000      C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\ClearTranProxy.dll
    0x745e0000 - 0x7489e000      C:\WINDOWS\system32\msi.dll
    0x71c40000 - 0x71c97000      C:\WINDOWS\system32\NETAPI32.dll
    0x4bc50000 - 0x4bc6c000      C:\WINDOWS\system32\DBNETLIB.DLL
    0x71f60000 - 0x71f64000      C:\WINDOWS\system32\security.dll
    0x76c90000 - 0x76cb7000      C:\WINDOWS\system32\msv1_0.dll
    0x76cf0000 - 0x76d0a000      C:\WINDOWS\system32\iphlpapi.dll
    0x761b0000 - 0x76243000      C:\WINDOWS\system32\crypt32.dll
    0x76190000 - 0x761a2000      C:\WINDOWS\system32\MSASN1.dll
    0x4bcf0000 - 0x4bcff000      C:\Program Files\Common Files\System\Ole DB\SQLOLEDB.RLL
    0x4a8a0000 - 0x4a8aa000      C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\MIGI.DLL
    0x73570000 - 0x736c2000      C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib\MSVBVM60.DLL
    0x4a950000 - 0x4a9e2000      C:\Program Files\Common Files\System\ado\msado15.dll
    0x74a50000 - 0x74a6a000      C:\WINDOWS\system32\MSDART.DLL
    0x4c850000 - 0x4c8c9000      C:\Program Files\Common Files\System\Ole DB\oledb32.dll
    0x4dbb0000 - 0x4dbc1000      C:\Program Files\Common Files\System\Ole DB\OLEDB32R.DLL
    VM Arguments:
    jvm_args: -Dcatalina.home=C:\Program Files\Apache Software Foundation\Tomcat 5.5 -Dcatalina.base=C:\Program Files\Apache Software Foundation\Tomcat 5.5 -Djava.endorsed.dirs=C:\Program Files\Apache Software Foundation\Tomcat 5.5\common\endorsed -Djava.io.tmpdir=C:\Program Files\Apache Software Foundation\Tomcat 5.5\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\logging.properties -Djava.library.path=C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\MMI\WEB-INF\lib vfprintf -Xms512m -Xmx1024m
    java_command: <unknown>
    Launcher Type: generic
    Environment Variables:
    JAVA_HOME=C:\Program Files\Java\jdk1.6.0_07
    [error occurred during error reporting (printing environment variables), id 0xc0000005]
    --------------- S Y S T E M ---------------
    OS: Windows Server 2003 family Build 3790 Service Pack 2
    CPU:total 4 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
    Memory: 4k page, physical 2097151k(2097151k free), swap 4194303k(4194303k free)
    vm_info: Java HotSpot(TM) Client VM (10.0-b23) for windows-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:14:11 by "java_re" with MS VC++ 7.1
    time: Mon Dec 28 15:24:00 2009
    elapsed time: 600 seconds

  • JVM core dump - JNI code

    I am using JNI in my Java application , 12 hours after running my test case get a JVM crash -
    1) These are the parameters with which i invoke my Java program
    java -d64 -Xcheck:jni -Xmx2560M -Xms2560M -Xss256k RunQueries
    2) The Heap output at the time of the core shows "from space" as 100% used , does this signify anything?
    Heap at VM Abort:
    Heap
    def new generation total 848128K, used 672342K [0xfffffffe93c00000, 0xfffffffec9150000, 0xfffffffec9150000)
    eden space 822464K, 78% used [0xfffffffe93c00000, 0xfffffffebb385b90, 0xfffffffec5f30000)
    from space 25664K, 100% used [0xfffffffec7840000, 0xfffffffec9150000, 0xfffffffec9150000)
    to space 25664K, 0% used [0xfffffffec5f30000, 0xfffffffec5f30000, 0xfffffffec7840000)
    tenured generation total 1747648K, used 1350866K [0xfffffffec9150000, 0xffffffff33c00000, 0xffffffff33c00000)
    the space 1747648K, 77% used [0xfffffffec9150000, 0xffffffff1b884830, 0xffffffff1b884a00, 0xffffffff33c00000)
    compacting perm gen total 16384K, used 13550K [0xffffffff33c00000, 0xffffffff34c00000, 0xffffffff37c00000)
    the space 16384K, 82% used [0xffffffff33c00000, 0xffffffff3493b860, 0xffffffff3493ba00, 0xffffffff34c00000)
    Local Time = Mon Feb 12 21:49:40 2007
    Elapsed Time = 61687
    # The exception above was detected in native code outside the VM
    # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.2_07-b05 mixed mode)
    3) A dbx on the Java core shows the location in the JNI code where the core dump occured.
    dbx `which java` core
    For information about new features see `help changes'
    To remove this message, put `dbxenv suppress_startup_message 7.3' in your .dbxrc
    Reading java
    dbx: internal warning: writable memory segment 0x7cb00000[16384] of size 0 in core
    core file header read successfully
    Reading ld.so.1
    Reading libthread.so.1
    Reading libdl.so.1
    Reading libc.so.1
    Reading libc_psr.so.1
    Reading libjvm.so
    Reading libCrun.so.1
    Reading libsocket.so.1
    Reading libnsl.so.1
    Reading libm.so.1
    WARNING!!
    A loadobject was found with an unexpected checksum value.
    See `help core mismatch' for details, and run `proc -map'
    to see what checksum values were expected and found.
    dbx: warning: Some symbolic information might be incorrect.
    t@1 (l@1) terminated by signal ABRT (Abort)
    0xffffffff7eea822c: lwpkill+0x0008: bcc,a,pt %icc,_lwp_kill+0x18 ! 0xffffffff7eea823c
    Current function is Java_getLoid (optimized)
    7239 e = cod_to_long (*(o_object*) data, &loid_as_long);
    (dbx) where
    current thread: t@1
    [1] lwpkill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7eea822c
    [2] raise(0x6, 0x0, 0xffffffff7fffad30, 0x7fbffeff00003ff6, 0x0, 0x2), at 0xffffffff7ee58a8c
    [3] abort(0x0, 0xffffffff7fffae10, 0x0, 0xfffffffffffffff8, 0x0, 0xffffffff7fffae39), at 0xffffffff7ee3e3b8
    [4] os::abort(0x1, 0xffffffff7e9d295c, 0xffffffff7fffaf10, 0xffffffff7e9d24a9, 0x4b007c, 0xffffffff7eb78878), at 0xffffffff7e90951c
    [5] os::handle_unexpected_exception(0x10011e600, 0xa, 0xfffffffe90345704, 0xffffffff7fffbeb0, 0xffffffff7e69c6f8, 0x0), at 0xffffffff7e907e08
    [6] JVM_handle_solaris_signal(0xffffffff7fffbeb0, 0xffffffff7e9d443e, 0xffffffff7fffbbd0, 0x1, 0x0, 0x1), at 0xffffffff7e69c800
    [7] __sighndlr(0xa, 0xffffffff7fffbeb0, 0xffffffff7fffbbd0, 0xffffffff7e69cb9c, 0x0, 0x0), at 0xffffffff7f2188d8
    ---- called from signal handler with signal 10 (SIGBUS) ------
    =>[8] Java_getLoid(vjEnv = ???, cls = ???, handle = ???, attr = ???) (optimized), at 0xfffffffe90345704 (line ~7239) in "j.c"
    I have added checks for this function call to ensure that no invalid pointer is being sent to it which could cause a segmentation violation.
    Please could someone give me some pointers on how to solve this problem, the error occurs at this point only 12 hours after running the test case..

    First step is to add the option -Xcheck:jni to your java command line. It will flag common JNI errors.
    If that doesn't identify the problem, then compile your jni code with debugging symbols (-g) and add the following option to the java command line when you run your test: -XX:+ShowMessageBoxOnError. When you hit the problem again, the VM will keep the process alive instead of calling abort(). Then you can use dbx to attach to the live process and should be able to get a better idea of what went wrong.

  • Error in Java Runtime Environment when running JNI native library

    Hi,
    I am kinda new to JNI but understand it [and done some tutorials]. I am trying to implement JavaStyle [ a Java vst host that uses JNI ] and have reached a point where i successfully build the native code to a dll, and almost manage to load the native dll library. I do not get a Unsatisfied Link Error, but instead have the JVM close due an internal error.
    I am completely lost and dont know what to try now, and I would appreciate any help offered.
    I have debugged and the error arrives at the System.load line of code:
      static {
        System.out.print("Pre loadLibrary..."); 
        System.loadLibrary("JaVaSTyle");
        System.out.println("JavaStyle dll loaded in JVSTLibrary");
      }Detail: I compiled the native library with MS visual studio .NET 2003 using the project settings supplied from the CVS repository.
    I use Netbeans 6.0 for the java side of things. The console output is:
    # An unexpected error has been detected by Java Runtime Environment:
    #  Internal Error (0xe0434f4d), pid=1500, tid=6012
    # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing)
    # Problematic frame:
    # C  [kernel32.dll+0x12a5b]
    # An error report file with more information is saved as hs_err_pid1500.logand the error report is :
    # An unexpected error has been detected by Java Runtime Environment:
    #  Internal Error (0xe0434f4d), pid=1500, tid=6012
    # Java VM: Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing)
    # Problematic frame:
    # C  [kernel32.dll+0x12a5b]
    # If you would like to submit a bug report, please visit:
    #   http://java.sun.com/webapps/bugreport/crash.jsp
    ---------------  T H R E A D  ---------------
    Current thread (0x00297000):  JavaThread "main" [_thread_in_native, id=6012]
    siginfo: ExceptionCode=0xe0434f4d
    Registers:
    EAX=0x0090f4c0, EBX=0x00000001, ECX=0x000b0fd0, EDX=0x00000000
    ESP=0x0090f4bc, EBP=0x0090f510, ESI=0x00000000, EDI=0x00000000
    EIP=0x7c812a5b, EFLAGS=0x00000246
    Top of Stack: (sp=0x0090f4bc)
    0x0090f4bc:   000b0fd0 e0434f4d 00000001 00000000
    0x0090f4cc:   7c812a5b 00000000 791b9d02 02ea1198
    0x0090f4dc:   07624998 000b0fd0 0090f4fc 791be271
    0x0090f4ec:   000ae008 00000002 07624998 00000000
    0x0090f4fc:   0090f50c 791be286 000ae008 07624998
    0x0090f50c:   0090f51c 0090f568 7921020d e0434f4d
    0x0090f51c:   00000001 00000000 00000000 000b0fd0
    0x0090f52c:   0090f578 00000001 7c812a5b 0090f1f0
    Instructions: (pc=0x7c812a5b)
    0x7c812a4b:   8d 7d c4 f3 a5 5f 8d 45 b0 50 ff 15 08 15 80 7c
    0x7c812a5b:   5e c9 c2 10 00 85 ff 0f 8e 36 93 ff ff 8b 55 fc
    Stack: [0x008c0000,0x00910000),  sp=0x0090f4bc,  free space=317k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    C  [kernel32.dll+0x12a5b]
    C  [mscorwks.dll+0x6020d]
    C  [mscorwks.dll+0x60190]
    C  [mscorwks.dll+0x60144]
    C  [mscorwks.dll+0xa6dcb]
    C  [mscorwks.dll+0x26a7e]
    C  0x000b15f6
    j  java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V+0
    j  java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+300
    j  java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+268
    j  java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54
    j  java.lang.System.loadLibrary(Ljava/lang/String;)V+7
    j  org.tango.JaVaSTyle.JVSTLibrary.<clinit>()V+10
    v  ~StubRoutines::call_stub
    Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
    j  java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V+0
    j  java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+300
    j  java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+268
    j  java.lang.Runtime.loadLibrary0(Ljava/lang/Class;Ljava/lang/String;)V+54
    j  java.lang.System.loadLibrary(Ljava/lang/String;)V+7
    j  org.tango.JaVaSTyle.JVSTLibrary.<clinit>()V+10
    v  ~StubRoutines::call_stub
    j  org.tango.JaVaSTyle.Main.main([Ljava/lang/String;)V+3
    v  ~StubRoutines::call_stub
    ---------------  P R O C E S S  ---------------
    Java Threads: ( => current thread )
      0x02a6d800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=4752]
      0x02a68c00 JavaThread "CompilerThread0" daemon [_thread_blocked, id=4472]
      0x02a67800 JavaThread "Attach Listener" daemon [_thread_blocked, id=2016]
      0x02a66c00 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4328]
      0x02a62400 JavaThread "Finalizer" daemon [_thread_blocked, id=5072]
      0x02a5dc00 JavaThread "Reference Handler" daemon [_thread_blocked, id=5552]
    =>0x00297000 JavaThread "main" [_thread_in_native, id=6012]
    Other Threads:
      0x02a5cc00 VMThread [id=4660]
      0x02a6f000 WatcherThread [id=3864]
    VM state:not at safepoint (normal execution)
    VM Mutex/Monitor currently owned by a thread: None
    Heap
    def new generation   total 960K, used 199K [0x22970000, 0x22a70000, 0x22e50000)
      eden space 896K,  22% used [0x22970000, 0x229a1ff0, 0x22a50000)
      from space 64K,   0% used [0x22a50000, 0x22a50000, 0x22a60000)
      to   space 64K,   0% used [0x22a60000, 0x22a60000, 0x22a70000)
    tenured generation   total 4096K, used 0K [0x22e50000, 0x23250000, 0x26970000)
       the space 4096K,   0% used [0x22e50000, 0x22e50000, 0x22e50200, 0x23250000)
    compacting perm gen  total 12288K, used 23K [0x26970000, 0x27570000, 0x2a970000)
       the space 12288K,   0% used [0x26970000, 0x26975c48, 0x26975e00, 0x27570000)
        ro space 8192K,  66% used [0x2a970000, 0x2aebf860, 0x2aebfa00, 0x2b170000)
        rw space 12288K,  52% used [0x2b170000, 0x2b7bf078, 0x2b7bf200, 0x2bd70000)
    Dynamic libraries:
    0x00400000 - 0x00423000      C:\Program Files\Java\jdk1.6.0_03\jre\bin\java.exe
    0x7c900000 - 0x7c9b0000      C:\WINDOWS\system32\ntdll.dll
    0x7c800000 - 0x7c8f5000      C:\WINDOWS\system32\kernel32.dll
    0x77dd0000 - 0x77e6b000      C:\WINDOWS\system32\ADVAPI32.dll
    0x77e70000 - 0x77f02000      C:\WINDOWS\system32\RPCRT4.dll
    0x77fe0000 - 0x77ff1000      C:\WINDOWS\system32\Secur32.dll
    0x7c340000 - 0x7c396000      C:\Program Files\Java\jdk1.6.0_03\jre\bin\msvcr71.dll
    0x6d870000 - 0x6daba000      C:\Program Files\Java\jdk1.6.0_03\jre\bin\client\jvm.dll
    0x7e410000 - 0x7e4a0000      C:\WINDOWS\system32\USER32.dll
    0x77f10000 - 0x77f57000      C:\WINDOWS\system32\GDI32.dll
    0x76b40000 - 0x76b6d000      C:\WINDOWS\system32\WINMM.dll
    0x76390000 - 0x763ad000      C:\WINDOWS\system32\IMM32.DLL
    0x5cd70000 - 0x5cd77000      C:\WINDOWS\system32\serwvdrv.dll
    0x5b0a0000 - 0x5b0a7000      C:\WINDOWS\system32\umdmxfrm.dll
    0x003a0000 - 0x003ad000      C:\WINDOWS\system32\myokent.dll
    0x6d3c0000 - 0x6d3c8000      C:\Program Files\Java\jdk1.6.0_03\jre\bin\hpi.dll
    0x76bf0000 - 0x76bfb000      C:\WINDOWS\system32\PSAPI.DLL
    0x6d820000 - 0x6d82c000      C:\Program Files\Java\jdk1.6.0_03\jre\bin\verify.dll
    0x6d460000 - 0x6d47f000      C:\Program Files\Java\jdk1.6.0_03\jre\bin\java.dll
    0x6d860000 - 0x6d86f000      C:\Program Files\Java\jdk1.6.0_03\jre\bin\zip.dll
    0x10000000 - 0x10018000      D:\NetbeansWorkspace\myJavaStyle\JaVaSTyle.dll
    0x79170000 - 0x79196000      C:\WINDOWS\system32\mscoree.dll
    0x10480000 - 0x1053c000      C:\WINDOWS\system32\MSVCP71D.dll
    0x10200000 - 0x10287000      C:\WINDOWS\system32\MSVCR71D.dll
    0x77f60000 - 0x77fd6000      C:\WINDOWS\system32\SHLWAPI.dll
    0x77c10000 - 0x77c68000      C:\WINDOWS\system32\msvcrt.dll
    0x791b0000 - 0x79412000      C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll
    0x79040000 - 0x79085000      C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\fusion.dll
    0x7c9c0000 - 0x7d1d6000      C:\WINDOWS\system32\SHELL32.dll
    0x773d0000 - 0x774d3000      C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2982_x-ww_ac3f9c03\comctl32.dll
    0x5d090000 - 0x5d12a000      C:\WINDOWS\system32\comctl32.dll
    0x79780000 - 0x79980000      c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll
    0x774e0000 - 0x7761d000      C:\WINDOWS\system32\ole32.dll
    0x79430000 - 0x7947c000      C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\MSCORJIT.DLL
    0x51a70000 - 0x51af0000      C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\diasymreader.dll
    VM Arguments:
    java_command: org.tango.JaVaSTyle.Main
    Launcher Type: SUN_STANDARD
    Environment Variables:
    CLASSPATH=.;C:\jdk1.5.0_09\bin;C:\Program Files\Java\jre1.6.0_03\lib\ext\QTJava.zip
    PATH=C:\Program Files\MiKTeX 2.7\miktex\bin;c:\program files\imagemagick-6.3.7-q16;C:\texmf\miktex\bin;C:\Program Files\ActiveState Komodo IDE 4.2\;C:\Program Files\Autodesk\Maya2008\bin;C:\Python25\;C:\Program Files\PC Connectivity Solution\;C:\ORANT\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Common Files\Roxio Shared\DLLShared;C:\Program Files\ATI Technologies\ATI Control Panel;C:\Program Files\GPS Pathfinder Office 3.00;C:\WINDOWS\system32\nls;C:\WINDOWS\system32\nls\ENGLISH;C:\Program Files\Common Files\Motorola\Toolbox;C:\PROGRA~1\COMMON~1\Motorola\Toolbox;C:\Program Files\Novell\ZENworks\;C:\Program Files\Novell\SecureLogin;C:\Program Files\Smart Projects\IsoBuster;C:\Latex\MikTeX\V2.10;C:\PROGRA~1\CA\Common\SCANEN~1;C:\Program Files\CA\Common\ScanEngine;C:\Program Files\CA\SharedComponents\CAUpdate\;C:\Program Files\CA\SharedComponents\ThirdParty\;C:\Program Files\CA\SharedComponents\SubscriptionLicense\;C:\PROGRA~1\CA\ETRUST~1;C:\Program Files\QuickTime\QTSystem\;C:\cygwin\bin;C:\Program Files\Tcl\bin;D:\netbeansWorkspace\myJavaStyle;C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual Studio\Common\Tools;C:\Program Files\Microsoft Visual Studio\VC98\bin;C:\Program Files\Csound\bin;C:\Program Files\CVSNT\
    USERNAME=hectorj
    OS=Windows_NT
    PROCESSOR_IDENTIFIER=x86 Family 6 Model 13 Stepping 8, GenuineIntel
    ---------------  S Y S T E M  ---------------
    OS: Windows XP Build 2600 Service Pack 2
    CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 13 stepping 8, cmov, cx8, fxsr, mmx, sse, sse2
    Memory: 4k page, physical 1047920k(270244k free), swap 2520456k(1654520k free)
    vm_info: Java HotSpot(TM) Client VM (1.6.0_03-b05) for windows-x86, built on Sep 24 2007 22:24:33 by "java_re" with unknown MS VC++:1310

    Something is wrong with the library.
    Staring at java code will not help you figure that out.
    Maybe it isn't intended to be loaded in java but instead it loads java itself?
    If not then write a C/C++ basic app that links that dll in and see if you can at least get it to start.

  • [JNI Beginner] GC of Java arrays returned by the native code

    Hello all,
    I am beginning with JNI, to integrate a C library that pilots an industrial equipment, into a java UI. This library enables to exchange various proprietary PDUs (protocol data units), with the equipment, up and down (request/replies). Both requests and replies are arrays of bytes (+char*+).
    "Request" byte arrays are constructed by Java code, which passes them to the JNI code that glues with the lib. "Reply" byte arrays are returned to the Java code, which analyzes them.
    The "return reply" part is very similar to this [tutorial example|http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html] , which returns bytes read from a file. However there's something I don't understand with regard to garbage collection of the returned byte array:
    - in this stock example, the C code creates a Java byte array fills it, and simply returns it (example code stripped to highlight only the parts relevant to my question):
        jByteArray=(*env)->NewByteArray(env, size);
        (*env)->SetByteArrayRegion(env, jByteArray, 0, size, (jbyte *)sourceBytes);
        return (jByteArray);What will happen to this Java array (jByteArray) with regard to garbage collection?
    - if it's no more referenced (the example Java code just systemouts it and forgets it), will it be eligible to GC?
    - if it is referenced by a Java variable (in my case, I plan to keep a reference to several replies as the business logic requires to analyze several of them together), do regular Java language GC rules apply, and prevent eligibility of the array to GC as long as it's referenced?
    That may sound obvious, but what mixes me up is that the same tutorial describes memory issues in subsequent chapters: spécifically, the section on "passing arrays states that:
    [in the example] the array is returned to the calling Java language method, which in turn, garbage collects the reference to the array when it is no longer usedThis seems to answer "yes" to both my questions above :o) But it goes on:
    The array can be explicitly freed with the following call:
    {code} (*env)-> ReleaseByteArrayElements(env, jByteArray, (jbyte *)sourceBytes, 0);{code}Under what circumstances would one need to explicitly free jByteArray when it's about to be returned to the Java calling method? Or does this sentence apply to completely different situations (such as, when the array is +not+ returned as is to a Java method)?
    The tutorial's next section has a much-expected +memory issues+ paragraph, from which I quote:
    By default, JNI uses local references when creating objects inside a native method. This means when the method returns, the references are eligible to be garbage collected.I assume this means, +unless the references are assigned, in the Java code, to a Java variable+, right?
    If you want an object to persist across native method calls, use a global reference instead. A global reference is created from a local reference by calling NewGlobalReference on the the local reference.I assume this enables the C code to maintain a global reference to a java object even if it's not referenced anymore from the Java variables, right?
    I also checked the [JNI specification|http://download-llnw.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp1242] , but this didn't clear the doubt completely:
    *Global and Local References*
    The JNI divides object references used by the native code into two categories: local and global references. Local references are valid for the duration of a native method call, and are automatically freed after the native method returns. Global references remain valid until they are explicitly freed.
    Objects are passed to native methods as local references. All Java objects returned by JNI functions are local references. The JNI allows the programmer to create global references from local references. JNI functions that expect Java objects accept both global and local references. A native method may return a local or global reference to the VM as its resultAgain I assume the intent is that Global references are meant for objects that have to survive across native calls, regardless of whether they are referenced by Java code. But what worries me is that combining both sentences end up in +All Java objects returned by JNI functions are local references (...) and are automatically freed after the native method returns.+.
    Could you clarify how to make sure that my Java byte arrays, be they allocated in C code, behave consistently with a Java array allocated in Java code (I'm familiar already with GC of "regular" Java objects)?
    Thanks in advance, and best regards,
    J.

    jduprez wrote:
    Hello all,
    I am beginning with JNI, to integrate a C library that pilots an industrial equipment, into a java UI. This library enables to exchange various proprietary PDUs (protocol data units), with the equipment, up and down (request/replies). Both requests and replies are arrays of bytes (+char*+).
    "Request" byte arrays are constructed by Java code, which passes them to the JNI code that glues with the lib. "Reply" byte arrays are returned to the Java code, which analyzes them.
    The "return reply" part is very similar to this [tutorial example|http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.html] , which returns bytes read from a file. However there's something I don't understand with regard to garbage collection of the returned byte array:
    - in this stock example, the C code creates a Java byte array fills it, and simply returns it (example code stripped to highlight only the parts relevant to my question):
        jByteArray=(*env)->NewByteArray(env, size);
    (*env)->SetByteArrayRegion(env, jByteArray, 0, size, (jbyte *)sourceBytes);
    return (jByteArray);What will happen to this Java array (jByteArray) with regard to garbage collection?It will be collected when it is no longer referenced.
    The fact that you created it in jni doesn't change that.
    The array can be explicitly freed with the following call:
    (*env)-> ReleaseByteArrayElements(env, jByteArray, (jbyte *)sourceBytes, 0);Under what circumstances would one need to explicitly free jByteArray when it's about to be returned to the Java calling method? Or does this sentence apply to completely different situations (such as, when the array is not returned as is to a Java method)?
    Per what the tutorial says it is either poorly worded or just wrong.
    An array which has been properly initialized it a just a java object. Thus it can be freed like any other object.
    Per your original question that does not concern you because you return it.
    In terms of why you need to explicitly free local references.
    [http://download-llnw.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp16785]
    The tutorial's next section has a much-expected memory issues paragraph, from which I quote:
    By default, JNI uses local references when creating objects inside a native method. This means when the method returns, the references are eligible to be garbage collected.I assume this means, unless the references are assigned, in the Java code, to a Java variable, right?As stated it is not precise.
    The created objects are tracked by the VM. When they are eligible to be collected they are.
    If you create a local reference and do NOTHING that creates an active reference elsewhere then when the executing thread returns to the VM then the local references are eligible to be collected.
    >
    If you want an object to persist across native method calls, use a global reference instead. A global reference is created from a local reference by calling NewGlobalReference on the the local reference.That is not precise. The scope is the executing thread. You can pass a local reference to another method without problem.
    I assume this enables the C code to maintain a global reference to a java object even if it's not referenced anymore from the Java variables, right?
    It enables access to it to be insured across multiple threads in terms of execution scope. Normally you should not use them.

  • JVM Crashes in Native Code - JDK#1.4.2_10 for solaris-sparc

    Hi,
    We are facing irregular but quite frequent JVM crash in our Test environment. From the stacktrace it seems that JVM is crashing inside the native code. Can anyone help me in finding the cause of this problem please?
    Please find below the dump generated after JVM crash -
    # An unexpected error has been detected by HotSpot Virtual Machine:
    # SIGBUS (0xa) at pc=0xfea32db4, pid=4695, tid=1
    # Java VM: Java HotSpot(TM) Client VM (1.4.2_10-b03 mixed mode)
    # Problematic frame:
    # C [libzip.so+0x2db4]
    --------------- T H R E A D ---------------
    Current thread (0x0003c2f0): JavaThread "main" [_thread_in_native, id=1]
    siginfo:si_signo=10, si_errno=151, si_code=3, si_addr=0xfe3a11cd
    Registers:
    O0=0xfe390000 O1=0x000111cc O2=0xffbfa350 O3=0x0003c4a0
    O4=0xff02aa10 O5=0xff008000 O6=0xffbfa1f0 O7=0xfea32d90
    G1=0x506f6c6c G2=0xff362a00 G3=0x0003c2f0 G4=0x00000066
    G5=0xf58d6cd8 G6=0x00000000 G7=0xff362a00 Y=0x00000000
    PC=0xfea32db4 nPC=0xfea32db8
    Top of Stack: (sp=0xffbfa1f0)
    0xffbfa1f0: 001de478 001deda8 fe3a11cc 00000000
    0xffbfa200: 00000000 fea40000 00000000 00000000
    0xffbfa210: 001de478 001deda8 0000506f 4f6d734e
    0xffbfa220: 80808080 01010101 ffbfa250 fea32ce0
    0xffbfa230: 00000000 2f3cbdc2 2f3cbdc2 f19cdfe8
    0xffbfa240: 0003c8b0 0003c8b0 ffbfa2b8 0000002b
    0xffbfa250: 001de478 ffbfa314 00000000 001deda8
    0xffbfa260: f206a1aa 00000043 0000ffff ff01f8a8
    Instructions: (pc=0xfea32db4)
    0xfea32da4: aa 02 40 0f d2 04 60 00 a4 02 00 09 a0 10 00 18
    0xfea32db4: d4 0c a0 01 95 2a a0 08 d0 0a 00 09 90 12 00 0a
    Stack: [0xffb7c000,0xffc00000), sp=0xffbfa1f0, free space=504k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    C [libzip.so+0x2db4]
    C [libzip.so+0x2ce8] ZIP_GetEntry+0xe0
    C [libzip.so+0x3488] Java_java_util_zip_ZipFile_getEntry+0x9c
    J java.util.zip.ZipFile.getEntry(JLjava/lang/String;)J
    J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
    J java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
    J sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;
    J sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;
    J java.net.URLClassLoader$1.run()Ljava/lang/Object;
    v ~StubRoutines::call_stub
    V [libjvm.so+0xc9ccc]
    V [libjvm.so+0xd6a34]
    C [libjava.so+0xdc38] Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_secu
    rity_AccessControlContext_2+0x1c
    J java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)L
    java/lang/Object;
    J java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;
    J java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;
    J sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;
    J java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;
    J java.lang.ClassLoader.loadClassInternal(Ljava/lang/String;)Ljava/lang/Class;
    v ~StubRoutines::call_stub
    V [libjvm.so+0xc9ccc]
    V [libjvm.so+0xd1cec]
    V [libjvm.so+0xf43a0]
    V [libjvm.so+0x9ce34]
    V [libjvm.so+0x9c2c4]
    V [libjvm.so+0x9be3c]
    V [libjvm.so+0x9bbc4]
    V [libjvm.so+0xcbec8]
    V [libjvm.so+0xd0b84]
    j be.telenet.rts.oms.dbpoller.PollOmsNotificationTable.processDeleteOfAging(Lbe/telenet/rts/oms/dbpoller/OmsNotificationDataV
    O;)V+4
    J be.telenet.rts.oms.dbpoller.PollOmsNotificationTable.processOmsNotificationData(Ljava/util/Collection;)V
    J be.telenet.rts.oms.dbpoller.PollOmsNotificationTable.pollTable()V
    v ~RuntimeStub::osr_frame_return Runtime1 stub
    j be.telenet.rts.oms.dbpoller.ILMAdapter_NotifierPoller.main([Ljava/lang/String;)V+30
    v ~StubRoutines::call_stub
    V [libjvm.so+0xc9ccc]
    V [libjvm.so+0xdde98]
    V [libjvm.so+0x16791c]
    C [java+0x2f94] main+0x167c
    Thanks & Regards,
    Anuj

    Here's the exception I'm getting (slightly sanitized):
    Java Plug-in 1.4.2_10
    Using JRE version 1.4.2_10 Java HotSpot(TM) Client VM
    User home directory = C:\Documents and Settings\tvalesky
    c: clear console window
    f: finalize objects on finalization queue
    g: garbage collect
    h: display this help message
    l: dump classloader list
    m: print memory usage
    o: trigger logging
    q: hide console
    r: reload policy configuration
    s: dump system and deployment properties
    t: dump thread list
    v: dump thread stack
    x: clear classloader cache
    0-5: set trace level to
    load: class appls/DOLARS/user/Applet.class not found.
    java.lang.ClassNotFoundException: appls.DOLARS.user.Applet.class
         at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
         at java.lang.ClassLoader.loadClass(Unknown Source)
         at java.lang.ClassLoader.loadClass(Unknown Source)
         at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
         at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
         at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
         at java.lang.Thread.run(Unknown Source)
    Caused by: java.io.IOException: open HTTP connection failed:http://hostname.com/DOLARS.testing/dolars.testbed/classes/appls%2fDOLARS%2fuser%2fApplet%2fclass.class
         at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
         at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
         at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
         at java.security.AccessController.doPrivileged(Native Method)
         ... 7 more
    Exception: java.lang.ClassNotFoundException: appls.DOLARS.user.Applet.class

  • Thread local variable causes JVM crash through JNI

    Hi All,
    My team developed a JDBC driver which uses some native C codes. (Compiler: cl.exe, O/S: Windows XP)
    I found that JVM crashes at specific point. So I used debugger(Visual Studio 2005) to find the position.
    ==================File1.c=====================
    JNIEXPORT jbyteArray JNICALL
    Java_com_lone_wolf_MyClass_myFunc(
    JNIEnv *env, jclass cls,
    jint msgtype, jbyteArray recvarr)
    jbyteArray outarr;
    int x = 3;
    outarr = my_initializer (int &x);
    return outarr;
    ==================File2.c=====================
    __declspec(thread) int thread_id;
    static jbyteArray my_initializer (int *a)
    thread_id = *a; // HERE JVM CRASHES
    When my_initializer() tries to put *a into thread_id, JVM crashed with the following error message.
    # An unexpected error has been detected by HotSpot Virtual Machine:
    # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x4931c6bf, pid=3560, tid=848
    # Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode)
    # Problematic frame:
    # C [hello.dll+0xc6bf]
    --------------- T H R E A D ---------------
    Current thread (0x00037168): JavaThread "main" [_thread_in_native, id=848]
    Stack: [0x00040000,0x00080000), sp=0x0007f494, free space=253k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    C [hello.dll+0xc6bf]
    C [hello.dll+0xbebb]
    C [hello.dll+0x3c30]
    C [hello.dll+0x18e6]
    C [hello.dll+0x11b8]
    j com.lone.wolf.MyClass.myFunc(I[B)[B+0
    v ~StubRoutines::call_stub
    V [jvm.dll+0x8176e]
    V [jvm.dll+0xd481d]
    V [jvm.dll+0x8163f]
    V [jvm.dll+0x885cd]
    C [java.exe+0x14c0]
    C [java.exe+0x64cd]
    C [kernel32.dll+0x16ff7]
    VM Arguments:
    jvm_args: -Xms128m -Xmx1024m
    java_command: sampler.Sampler
    --------------- S Y S T E M ---------------
    OS: Windows XP Build 2600 Service Pack 2
    CPU:total 4 family 6, cmov, cx8, fxsr, mmx, sse, sse2, ht
    Memory: 4k page, physical 2062180k(1378880k free), swap 4003992k(3252828k free)
    vm_info: Java HotSpot(TM) Client VM (1.5.0_01-b08) for windows-x86, built on Dec 6 2004 19:51:00 by "java_re" with MS VC++ 6.0
    Any idea how to solve this issue will be greatly appreciated.
    Thank you.

    This deffinition ( __declspec(thread) ) of the thread local veriable does not works in some cases (see articles in MSDN how to define thread local variables in C++ code). JVM loads your native module (DLL) with LoadLibrary function. This is one of the cases when __declspec(thread) is wrong in C++ code.

  • JVM crashed when attempting to load native binaries on SUSE

    Hello!
    We have a java application that calls at some point C++ code in form of specific OS binaries. We tested for RedHat and SUSE - for the first OS it worked fine but for SUSE I got:
    {color:#ff0000}#
    # A fatal error has been detected by the Java Runtime Environment:
    # SIGFPE (0x8) at pc=0xf7f4a1fb, pid=21443, tid=4149328800
    # JRE version: 6.0_14-b08
    # Java VM: Java HotSpot(TM) Client VM (14.0-b16 mixed mode linux-x86 )
    # Problematic frame:
    # C [ld-linux.so.2+0x91fb]
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    # The crash happened outside the Java Virtual Machine in native code.
    # See problematic frame for where to report the bug.
    T H R E A D
    Current thread (0x08059000): JavaThread "main" [_thread_in_native, id=21448, stack(0xf749b000,0xf751c000)]
    siginfo:si_signo=SIGFPE: si_errno=0, si_code=1 (FPE_INTDIV), si_addr=0xf7f4a1fb
    Registers:
    EAX=0x0df0d414, EBX=0xf7f5bff4, ECX=0x093522b0, EDX=0x00000000
    ESP=0xf7517b84, EBP=0xf7517be0, ESI=0x0935245c, EDI=0xf7517c6c
    EIP=0xf7f4a1fb, CR2=0xf7f33100, EFLAGS=0x00010246
    Top of Stack: (sp=0xf7517b84)
    0xf7517b84: ea91ab8b dc5cdb74 00000009 f7f04164
    0xf7517b94: dc5ccb9c 0df0d414 dc5cdb74 f7f4e389
    0xf7517ba4: 00000008 093522b0 dc5cb3ec dc5cdafc
    0xf7517bb4: dc5d4030 00000000 00000000 09053344
    0xf7517bc4: f7f5bff4 f7517ca0 dc5d3fb6 f7517c6c
    0xf7517bd4: f7f5bff4 0935245c f7517c6c f7517c80
    0xf7517be4: f7f4a587 f7517c6c 09352408 00000000
    0xf7517bf4: 00000000 00000001 00000000 00000000
    Instructions: (pc=0xf7f4a1fb)
    0xf7f4a1eb: 8b 8a 94 01 00 00 8b 45 b8 89 4d d4 89 d1 31 d2
    0xf7f4a1fb: f7 b1 6c 01 00 00 8b 81 70 01 00 00 8b 3c 90 85
    Stack: [0xf749b000,0xf751c000], sp=0xf7517b84, free space=498k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    C [ld-linux.so.2+0x91fb]
    C [ld-linux.so.2+0x9587]
    C [ld-linux.so.2+0xabff]
    C [ld-linux.so.2+0x11471]
    C [ld-linux.so.2+0xd3a6]
    C [ld-linux.so.2+0x10cb9]
    C [libdl.so.2+0xe4d]
    C [ld-linux.so.2+0xd3a6]
    C [libdl.so.2+0x12fc]
    C [libdl.so.2+0xd84] dlopen+0x44
    V [libjvm.so+0x3237c9]
    V [libjvm.so+0x288819]
    C [libjava.so+0xbcac] Java_java_lang_ClassLoader_00024NativeLibrary_load+0x6c
    j java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;)V+0
    j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+300
    j java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+127
    j java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+57
    j java.lang.System.load(Ljava/lang/String;)V+7
    j com.boss.media.util.DllUtils.LoadNativeDll(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;+404
    j com.boss.media.engine.StreamingEngine.getInstance(Ljava/lang/String;)Lcom/boss/media/engine/StreamingEngine;+9
    {color:#000000}
    Seems the crash is producing when Suse's ld-linux.so attempts to load our binaries.{color}
    {color}{color:#000000}Does anyone have any idea on what is wrong here?
    Thank you very much
    With best regards,
    Sorin
    {color}

    We tested for RedHat and SUSE - for the first OS it worked fine but for SUSE I got:Either the standard pointer problems leading to a spurious error or some subtle OS difference.
    SIGFPEThat is a pretty specific signal. If the C++ code is not mucking around with numerics then it would suggest a pointer problem. If numerics are involved then that would be the first place to start (noting again that pointer problems can cause spurious errors.)

  • JVM crashes when starting application any ideals on what is causing it

    We are getting a error log generated when we startup our application. This does not occur often, but seems to happen in clusters(We get several crashes in a row) .
    # An unexpected error has been detected by HotSpot Virtual Machine:
    # SIGSEGV (0xb) at pc=0xb6bfe0a2, pid=10033, tid=1827658672
    # Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
    # Problematic frame:
    # V [libjvm.so+0x13b0a2]
    --------------- T H R E A D ---------------
    Current thread (0x6d002570): JavaThread "CompilerThread1" daemon [_thread_in_native, id=10042]
    siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000000
    Registers:
    EAX=0x00000000, EBX=0xb706e7f0, ECX=0x00000000, EDX=0x081d66e8
    ESP=0x6cefc624, EBP=0x6cefc668, ESI=0x081579c8, EDI=0x0000004f
    EIP=0xb6bfe0a2, CR2=0x00000000, EFLAGS=0x00010216
    Top of Stack: (sp=0x6cefc624)
    0x6cefc624: 0000004e 00000014 00000002 6cefc660
    0x6cefc634: b706e7f0 6cefc688 0818eacc 00000000
    0x6cefc644: 6d0c5288 00000000 00000000 081d7378
    0x6cefc654: 00000002 00000014 b706e7f0 b7017408
    0x6cefc664: 081c8cd0 6cefc6a8 b6bfde0d 081d66e8
    0x6cefc674: 081c8cd0 00000050 6cefc9e0 081579c8
    0x6cefc684: 081c8cd0 00000000 00000000 ffffffff
    0x6cefc694: 0000004e 00000004 b706e7f0 6cefcf90
    Instructions: (pc=0xb6bfe0a2)
    0xb6bfe092: 08 83 ec 0c 8b 42 04 8b 04 b8 89 45 d8 8b 4d d8
    0xb6bfe0a2: 8b 00 51 ff 90 c0 00 00 00 89 c6 89 04 24 e8 db
    Stack: [0x6ce7d000,0x6cefe000), sp=0x6cefc624, free space=509k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    V [libjvm.so+0x13b0a2]
    V [libjvm.so+0x13ae0d]
    V [libjvm.so+0x13b676]
    V [libjvm.so+0x4283e7]
    V [libjvm.so+0x1a216a]
    V [libjvm.so+0x19e46a]
    V [libjvm.so+0x1474b3]
    V [libjvm.so+0x1a6929]
    V [libjvm.so+0x1a6281]
    V [libjvm.so+0x4c8366]
    V [libjvm.so+0x4c2ba3]
    V [libjvm.so+0x424338]
    C [libpthread.so.0+0x4dec]
    Current CompileTask:
    opto: 3% com.sun.org.apache.bcel.internal.generic.InstructionList.setPositions(Z)V @ 28 (511
    bytes)
    --------------- P R O C E S S ---------------
    Java Threads: ( => current thread )
    0x6d003920 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=10043]
    =>0x6d002570 JavaThread "CompilerThread1" daemon [_thread_in_native, id=10042]
    0x6d001620 JavaThread "CompilerThread0" daemon [_thread_in_native, id=10041]
    0x6d000690 JavaThread "AdapterThread" daemon [_thread_blocked, id=10040]
    0x080f93b8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=10039]
    0x080f7f88 JavaThread "JDWP Event Helper Thread" daemon [_thread_blocked, id=10038]
    0x080f6388 JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_native, id=10037]
    0x080e7ed0 JavaThread "Finalizer" daemon [_thread_blocked, id=10036]
    0x080e68f8 JavaThread "Reference Handler" daemon [_thread_blocked, id=10035]
    0x0805da48 JavaThread "main" [_thread_in_Java, id=10033]
    Other Threads:
    0x080e4468 VMThread [id=10034]
    0x6d004e50 WatcherThread [id=10044]
    VM state:not at safepoint (normal execution)
    VM Mutex/Monitor currently owned by a thread: None
    Heap
    def new generation total 5760K, used 1820K [0x6da20000, 0x6e060000, 0x74be0000)
    eden space 5120K, 23% used [0x6da20000, 0x6db471c0, 0x6df20000)
    from space 640K, 100% used [0x6dfc0000, 0x6e060000, 0x6e060000)
    to space 640K, 0% used [0x6df20000, 0x6df20000, 0x6dfc0000)
    tenured generation total 51008K, used 2964K [0x74be0000, 0x77db0000, 0xada20000)
    the space 51008K, 5% used [0x74be0000, 0x74ec51c8, 0x74ec5200, 0x77db0000)
    compacting perm gen total 16384K, used 5615K [0xada20000, 0xaea20000, 0xb1a20000)
    the space 16384K, 34% used [0xada20000, 0xadf9bf20, 0xadf9c000, 0xaea20000)
    No shared spaces configured.
    Dynamic libraries:
    08048000-08057000 r-xp 00000000 68:05 69618 /usr/jdk1.5.0_06/bin/java
    08057000-08059000 rwxp 0000e000 68:05 69618 /usr/jdk1.5.0_06/bin/java
    08059000-08782000 rwxp 00000000 00:00 0
    6c300000-6c389000 rwxp 00060000 00:00 0
    6c389000-6c400000 ---p 00105000 00:00 0
    6c408000-6c40e000 r-xp 00000000 68:05 528500 /usr/jdk1.5.0_06/jre/lib/i386/libnio.so
    6c40e000-6c40f000 rwxp 00005000 68:05 528500 /usr/jdk1.5.0_06/jre/lib/i386/libnio.so
    6c40f000-6c423000 r-xp 00000000 68:05 528499 /usr/jdk1.5.0_06/jre/lib/i386/libnet.so
    6c423000-6c424000 rwxp 00013000 68:05 528499 /usr/jdk1.5.0_06/jre/lib/i386/libnet.so
    6c424000-6c4f7000 r-xs 00000000 68:0a 552745 /sssss/simulator/ttttt/wmbrokerclient.jar
    6c4f7000-6c4fe000 r-xs 00000000 68:0a 552713 /sssss/simulator/ttttt/jms.jar
    6c4fe000-6c654000 r-xs 00000000 68:0a 552723 /sssss/simulator/ttttt/ojdbc14_g.jar
    6c654000-6c67f000 r-xs 00000000 68:05 643160 /usr/jdk1.5.0_06/jre/lib/ext/sunpkcs11.jar
    6c67f000-6c6a5000 r-xs 00000000 68:05 643159 /usr/jdk1.5.0_06/jre/lib/ext/sunjce_provider.jar
    6c6a5000-6c769000 r-xs 00000000 68:05 643269 /usr/jdk1.5.0_06/jre/lib/ext/localedata.jar
    6c769000-6c76b000 r-xs 00000000 68:05 643157 /usr/jdk1.5.0_06/jre/lib/ext/dnsns.jar
    6c76b000-6cd7b000 r-xs 00000000 68:0a 552731 /sssss/simulator/ttttt/rtc.jar
    6cd7b000-6cd7c000 ---p 00000000 00:00 0
    6cd7c000-6cdfc000 rwxp 00001000 00:00 0
    6cdfc000-6cdff000 ---p 00000000 00:00 0
    6cdff000-6ce7d000 rwxp 00003000 00:00 0
    6ce7d000-6ce80000 ---p 00000000 00:00 0
    6ce80000-6cefe000 rwxp 00003000 00:00 0
    6cefe000-6cf01000 ---p 00000000 00:00 0
    6cf01000-6cf7f000 rwxp 00003000 00:00 0
    6cf7f000-6cf82000 ---p 00000000 00:00 0
    6cf82000-6d0fd000 rwxp 00003000 00:00 0
    6d0fd000-6d100000 ---p 00117000 00:00 0
    6d10a000-6d10d000 ---p 00000000 00:00 0
    6d10d000-6d18b000 rwxp 00003000 00:00 0
    6d18b000-6d18e000 ---p 00000000 00:00 0
    6d18e000-6d20d000 rwxp 00003000 00:00 0
    6d20d000-6d210000 ---p 00001000 00:00 0
    6d210000-6d28e000 rwxp 00004000 00:00 0
    6d28e000-6d292000 r-xp 00000000 68:05 528478 /usr/jdk1.5.0_06/jre/lib/i386/libdt_socket.so
    6d292000-6d293000 rwxp 00003000 68:05 528478 /usr/jdk1.5.0_06/jre/lib/i386/libdt_socket.so
    6d293000-6d493000 r-xp 00000000 68:05 458853 /usr/lib/locale/locale-archive
    6d493000-6d496000 ---p 00000000 00:00 0
    6d496000-6d514000 rwxp 00003000 00:00 0
    6d514000-6d517000 ---p 00000000 00:00 0
    6d517000-6d595000 rwxp 00003000 00:00 0
    6d595000-6d596000 ---p 00000000 00:00 0
    6d596000-6d61f000 rwxp 00001000 00:00 0
    6d61f000-6d637000 rwxp 00009000 00:00 0
    6d637000-6d650000 rwxp 00000000 00:00 0
    6d650000-6d7ff000 rwxp 00019000 00:00 0
    6d7ff000-6d803000 rwxp 00000000 00:00 0
    6d803000-6d837000 rwxp 00004000 00:00 0
    6d837000-6d851000 rwxp 00000000 00:00 0
    6d851000-6d9ff000 rwxp 00052000 00:00 0
    6d9ff000-6da07000 rwxp 00000000 00:00 0
    6da07000-6da1f000 rwxp 00208000 00:00 0
    6da1f000-6e060000 rwxp 00000000 00:00 0
    6e060000-74be0000 rwxp 00861000 00:00 0
    74be0000-77db0000 rwxp 00000000 00:00 0
    77db0000-ada20000 rwxp 0a5b1000 00:00 0
    ada20000-aea20000 rwxp 00000000 00:00 0
    aea20000-b1a20000 rwxp 41221000 00:00 0
    b1a28000-b1a2a000 rwxp 00000000 00:00 0
    b1a2a000-b1aa8000 rwxp 00002000 00:00 0
    b1aa8000-b1b28000 rwxp 00000000 00:00 0
    b1b28000-b3aa8000 rwxp 00080000 00:00 0
    b3aa8000-b42e3000 r-xs 00000000 68:05 86044 /usr/jdk1.5.0_06/jre/lib/charsets.jar
    b42e3000-b42f7000 r-xs 00000000 68:05 86043 /usr/jdk1.5.0_06/jre/lib/jce.jar
    b42f7000-b437c000 r-xs 00000000 68:05 86089 /usr/jdk1.5.0_06/jre/lib/jsse.jar
    b437c000-b43e5000 rwxp 00000000 00:00 0
    b43e5000-b69cd000 r-xs 00000000 68:05 86157 /usr/jdk1.5.0_06/jre/lib/rt.jar
    b69cd000-b69e0000 r-xp 00000000 68:05 528505 /usr/jdk1.5.0_06/jre/lib/i386/libzip.so
    b69e0000-b69e2000 rwxp 00012000 68:05 528505 /usr/jdk1.5.0_06/jre/lib/i386/libzip.so
    b69e2000-b6a03000 r-xp 00000000 68:05 528485 /usr/jdk1.5.0_06/jre/lib/i386/libjava.so
    b6a03000-b6a05000 rwxp 00020000 68:05 528485 /usr/jdk1.5.0_06/jre/lib/i386/libjava.so
    b6a05000-b6a10000 r-xp 00000000 68:05 528504 /usr/jdk1.5.0_06/jre/lib/i386/libverify.so
    b6a10000-b6a11000 rwxp 0000b000 68:05 528504 /usr/jdk1.5.0_06/jre/lib/i386/libverify.so
    b6a11000-b6a1c000 r-xp 00000000 68:02 32809 /lib/libnss_files-2.3.2.so
    b6a1c000-b6a1d000 rwxp 0000a000 68:02 32809 /lib/libnss_files-2.3.2.so
    b6a28000-b6a30000 rwxs 00000000 68:07 180228 /tmp/hsperfdata_rtc/10033
    b6a30000-b6a62000 r-xp 00000000 68:05 528491 /usr/jdk1.5.0_06/jre/lib/i386/libjdwp.so
    b6a62000-b6a63000 rwxp 00032000 68:05 528491 /usr/jdk1.5.0_06/jre/lib/i386/libjdwp.so
    b6a63000-b6a66000 rwxp 00000000 00:00 0
    b6a66000-b6a78000 r-xp 00000000 68:02 32793 /lib/libnsl-2.3.2.so
    b6a78000-b6a79000 rwxp 00011000 68:02 32793 /lib/libnsl-2.3.2.so
    b6a79000-b6a7b000 rwxp 00000000 00:00 0
    b6a8e000-b6aaf000 r-xp 00000000 68:02 65552 /lib/tls/libm-2.3.2.so
    b6aaf000-b6ab0000 rwxp 00021000 68:02 65552 /lib/tls/libm-2.3.2.so
    b6aba000-b6ac0000 r-xp 00000000 68:05 381015
    /usr/jdk1.5.0_06/jre/lib/i386/native_threads/libhpi.so
    b6ac0000-b6ac1000 rwxp 00006000 68:05 381015
    /usr/jdk1.5.0_06/jre/lib/i386/native_threads/libhpi.so
    b6ac1000-b6ac2000 rwxp 00001000 00:00 0
    b6ac2000-b6ac3000 r-xp 00000000 00:00 0
    b6ac3000-b7010000 r-xp 00000000 68:05 315481 /usr/jdk1.5.0_06/jre/lib/i386/server/libjvm.so
    b7010000-b7072000 rwxp 0054d000 68:05 315481 /usr/jdk1.5.0_06/jre/lib/i386/server/libjvm.so
    b7072000-b748a000 rwxp 00000000 00:00 0
    b748a000-b75bc000 r-xp 00000000 68:02 65550 /lib/tls/libc-2.3.2.so
    b75bc000-b75bf000 rwxp 00132000 68:02 65550 /lib/tls/libc-2.3.2.so
    b75bf000-b75c2000 rwxp 00000000 00:00 0
    b75c2000-b75c4000 r-xp 00000000 68:02 32789 /lib/libdl-2.3.2.so
    b75c4000-b75c5000 rwxp 00001000 68:02 32789 /lib/libdl-2.3.2.so
    b75c5000-b75d2000 r-xp 00000000 68:02 65554 /lib/tls/libpthread-0.60.so
    b75d2000-b75d3000 rwxp 0000c000 68:02 65554 /lib/tls/libpthread-0.60.so
    b75d3000-b75d5000 rwxp 00000000 00:00 0
    b75e8000-b75e9000 rwxp 00001000 00:00 0
    b75e9000-b75fe000 r-xp 00000000 68:02 32776 /lib/ld-2.3.2.so
    b75fe000-b75ff000 rwxp 00015000 68:02 32776 /lib/ld-2.3.2.so
    bfe00000-bfe03000 ---p 00000000 00:00 0
    bfe03000-c0000000 rwxp ffe04000 00:00 0
    VM Arguments:
    jvm_args: -DprocessName=Mex -Dconfig.dir=/sssss/simulator/ttttt/config
    -Dframework.properties=/sssss/simulator/ttttt/framework.properties
    -Drubberbands.dir=/sssss/simulator/ttttt/sase -Dcheckpointroot.dir=/sssss/simulator/ckpt/ttttt
    -Dcheckpoint.dir=/sssss/simulator/ckpt/ttttt/checkpoint -Xdebug
    -Xrunjdwp:transport=dt_socket,address=50002,server=y,suspend=n -Xms56M -Xmx1024M
    java_command: /sssss/simulator/ttttt/rtc.jar CentralizedController.xml
    Launcher Type: SUN_STANDARD
    Environment Variables:
    JAVA_HOME=/usr/java5
    PATH=/sssss/simulator/logs/ttttt:/usr/java/jre/bin:/usr/java/jre/bin:/usr/local/bin:/usr/kerberos/bin:/usr/java/jre/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:.:.:.
    LD_LIBRARY_PATH=/usr/jdk1.5.0_06/jre/lib/i386/server:/usr/jdk1.5.0_06/jre/lib/i386:/usr/jdk1.5.0_06/jre/../lib/i386:/sssss/simulator/ttttt/lib:/sssss/simulator/ttttt/utl_timer/lib:/sssss/simulator/ttttt/utl/lib:/sssss/simulator/ttttt/mqlib/lib:/sssss/simulator/ttttt/sdi/lib:/sssss/simulator/ttttt/sase/lib:/usr/lib
    SHELL=/bin/tcsh
    DISPLAY=rtcd05.rrr.kk:0.0
    HOSTTYPE=i386-linux
    OSTYPE=linux
    MACHTYPE=i386
    Signal Handlers:
    SIGSEGV: [libjvm.so+0x4fd530], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    SIGBUS: [libjvm.so+0x4fd530], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    SIGFPE: [libjvm.so+0x422860], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    SIGPIPE: [libjvm.so+0x422860], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    SIGILL: [libjvm.so+0x422860], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
    SIGUSR2: [libjvm.so+0x424bb0], sa_mask[0]=0x00000000, sa_flags=0x14000004
    SIGHUP: [libjvm.so+0x4245e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
    SIGQUIT: [libjvm.so+0x4245e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    SIGTERM: [libjvm.so+0x4245e0], sa_mask[0]=0x7ffbfeff, sa_flags=0x14000004
    --------------- S Y S T E M ---------------
    OS:Red Hat Enterprise Linux ES release 3 (Taroon Update 4)
    uname:Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:59:02 EST 2004 i686
    libc:glibc 2.3.2 NPTL 0.60
    rlimit: STACK 10240k, CORE infinity, NPROC 7168, NOFILE 1024, AS infinity
    load average:0.51 0.36 0.24
    CPU:total 4 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
    Memory: 4k page, physical 1190k(697k free), swap 2047k(2047k free)
    vm_info: Java HotSpot(TM) Server VM (1.5.0_06-b05) for linux-x86, built on Nov 10 2005 10:56:33
    by java_re with gcc 3.2.1-7a (J2SE release)

    The server JIT compiler is crashing.
    This could be an instance of bug 6332641, which will be fixed in 1.5.0_08. It has no known workaround, other than to exclude the method being compiled.
    You may want to file a bug.

Maybe you are looking for

  • Hardware fix for digital out issue

    Hi! i'm one of the thousand users who has the same problem with the line out / digital out output. i've been trying all the solutions found around the web: Reset the PRAM make an SMC reset pull in and out the headphones jack delete the plist file of

  • Java is 100% pure object oriented language or not?

    PLS help me...? I am get confussed. Java is 100% pure object oriented language or not?

  • Why is my browser blocking my webpage from running?

    I have just upgraded from dreamweaver 8 to dreamweaver 11.5.  When I try to preview my html page via dreamweaver, I always get a page is being blocked from IE.  This did not happen with dreamweaver 8.  Is there some setting I can configure so that I

  • Macbook wont load!!! CMD+R doesnt work!

    Hi! I just tried updating to OSX Yosemite, however halfway through the installation the Mac displayed a notice stating "an error occurred" and restarted. Since then i have been unable to boot up my macbook. If i try to boot normally it just gets stuc

  • I want to complain.

    about nokia care of indore. i bought x2-00 mobile on 13 august 2011 and since january 2012 its creating trouble for me. its getting switched off again and again and even not supporting my reliance sim. further the employee at nokia care of indore are