Forum Stats

  • 3,873,012 Users
  • 2,266,495 Discussions
  • 7,911,401 Comments

Discussions

Java application crashed during exit while using native dll

843829
843829 Member Posts: 49,201
edited Sep 20, 2010 10:24AM in Java Native Interface (JNI)
I've developed an java eclipse based plugin product. One of its plugin interacts with a native c++ dll to create a structured model. Later java application launches a C++ based application to open that model. I've no issues in creating the model backstore and no problem in invoking the c++ application with backstore data.

Problem happens when I exit my java application: Application crashes out. I'm using JDK 1.6 for java application, and VC2005 for creating the native dll. After downloading the symbols of some standard windows dll, my call stack shows the following -

msvcr80.dll!__crt_debugger_hook()
msvcr80.dll!__invalid_parameter() + 0x1d bytes
msvcr80.dll!__close() + 0x59 bytes
msvcr80.dll!__fclose_nolock() + 0x4c bytes
msvcr80.dll!_fclose() + 0x5f bytes
msvcr80.dll!__fcloseall() + 0x48 bytes
msvcr80.dll!___endstdio() + 0x13 bytes
msvcr80.dll!__initterm() + 0xf bytes
msvcr80.dll!___crtdll_callstaticterminators() + 0xf bytes
msvcr80.dll!___p__winver() + 0x1a1 bytes
[email protected]() + 0x1d bytes
[email protected]() + 0x14 bytes
[email protected]() - 0xfe bytes
[email protected]() + 0x42 bytes
kernel32.dll!7c81cb0e()
msvcr71.dll!__crtExitProcess(int status=0) Line 463 + 0x9 bytes C
msvcr71.dll!doexit(int code=0, int quick=0, int retcaller=0) Line 403 C
msvcr71.dll!exit(int code=0) Line 303 + 0xd bytes C
jvm.dll!AsyncGetCallTrace() + 0x3e4cd bytes
[Frames below may be incorrect and/or missing, no symbols loaded for jvm.dll]
msvcr71.dll!exit(int code=0) Line 303 + 0xd bytes C
jvm.dll!AsyncGetCallTrace() + 0x3e4cd bytes
[email protected]() + 0xc818d bytes
[email protected]() + 0xc746e bytes
[email protected]() + 0xc77bc bytes
[email protected]() + 0xc7be2 bytes
[email protected]() + 0x52d8c bytes
msvcr71.dll!_threadstartex(void * ptd=0x26c52440) Line 241 + 0x6 bytes C
[email protected]() + 0x37 bytes

It seems to be a problem with closing standard output stream. Any idea how to solve this problem?

Sajal.

Comments

  • jschellSomeoneStoleMyAlias
    jschellSomeoneStoleMyAlias Member Posts: 24,877 Gold Badge
    Sajal822 wrote:
    Any idea how to solve this problem?
    Find and fix your pointer bugs.
  • 843829
    843829 Member Posts: 49,201
    jschell wrote:
    Sajal822 wrote:
    Any idea how to solve this problem?
    Find and fix your pointer bugs.
    I would have been happy if you have asked me do in some other direction related to JNI side. I'm pretty sure there is no bug in my native dll. My native dll internally linked to lots of legacy dll (internal and 3rd party) to perform some actions. They do some console and file based logging. As the error indicates there's a problem in stdout stream of java and C runtime, my application crashes during exit.

    See this post - [javaw.exe crashing|http://forums.sun.com/thread.jspa?threadID=733949&messageID=11027809#11027809]

    Any thoughts on the original question??
  • jschellSomeoneStoleMyAlias
    jschellSomeoneStoleMyAlias Member Posts: 24,877 Gold Badge
    Sajal822 wrote:
    jschell wrote:
    Sajal822 wrote:
    Any idea how to solve this problem?
    Find and fix your pointer bugs.
    I would have been happy if you have asked me do in some other direction related to JNI side. I'm pretty sure there is no bug in my native dll. My native dll internally linked to lots of legacy dll (internal and 3rd party) to perform some actions.
    Since that isn't true of the JNI code itself it doesn't mean much. It can still be a bug in the JNI code.

    And it doesn't mean much as for the other code either. A pointer bug does not mean that it will cause an OS problem. The OS causes the crash when it sees a problem not when the bug occurs. And other apps might not run in such a way that the OS sees a problem.
    See this post - [javaw.exe crashing|http://forums.sun.com/thread.jspa?threadID=733949&messageID=11027809#11027809]

    Any thoughts on the original question??
    The simplest solution is don't use JNI. Wrap the dll in a executable, provide a comm API, run the executable in Java via Runtime.exec() and use the comm API to talk to it. Easier to debug and no possibility it can corrupt your java app.
  • 843829
    843829 Member Posts: 49,201
    jschell wrote:
    The simplest solution is don't use JNI. Wrap the dll in a executable, provide a comm API, run the executable in Java via Runtime.exec() and use the comm API to talk to it. Easier to debug and no possibility it can corrupt your java app.
    Yes, I'll keep inter-process communication mechanism as my last option to get the job done.

    I'll better explain my work environment here -
    - I've a singleton C++ service class resides in the native dll. this service is capable of creating multiple "model" object
    - Java "serviceproxy" class represents a service class of c++ side. It has few native methods to create/edit/delete model(proxy)
    - Java class(modelproxy) works as a proxy to "model" object created by the service object
    - Through JNI call I create model object and return an ID to the caller so java can talk back to the same model object through later JNI call.
    - There are almost ~50 JNI methods are defined inside modelproxy to operate on the model
    - native dll internally using other dependent 3rd party dll methods to perform the operations
    - After certain operation on each model, they are being saved and serviceproxy disposed.

    what you guys suggest for better solution..
  • 843829
    843829 Member Posts: 49,201
    Finally my actual problem of application crash is resolved. The problem was in using zlib library(v1.2.3). There is some problem with that library which was causing a corruption of file handle. After I have implemented a similar functionality using ifstream, my problem resolved. There is no crash now after I exit my java application with native dll.
This discussion has been closed.