This discussion is archived
5 Replies Latest reply: Nov 10, 2012 10:51 AM by jschellSomeoneStoleMyAlias RSS

Specific tags to be used for building library (.so) files in linux 64-bit?

Sreram Newbie
Currently Being Moderated
I am using Windows 7 64-bit but installed Fedora Linux x86_64 (v17 recent one) with Oracle VM Virtual box and tried to build my library file which uses JNI for its application. But every time i run my application, JVM crashes with SIGSEGV fault. For more information, i wasn't able to create the so file without the '-fPIC' tag. GCC (again recent one) was giving error. Am using the latest version of Oracle Java(1.7_09) downloaded from oracle website (Is Oracle java different from OpenJDK???).

I will try to post the logs today along with debugging info with -verbose:jni, but is there any specific additional tags to be used for avoiding the JNI crash?

The reason for me to ask this question is that it points to the same .so file of mine for the fault. Can it be due to some out-of-memory issue as am using Virtual machine?

Thanks,
Sreram

Edited by: Sreram on Nov 6, 2012 7:16 PM
  • 1. Re: Specific tags to be used for building library (.so) files in linux 64-bit?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    What makes you think this is a compiler option problem versus just a normal pointer bug in C/C++ code?
  • 2. Re: Specific tags to be used for building library (.so) files in linux 64-bit?
    EJP Guru
    Currently Being Moderated
    The reason for me to ask this question is that it points to the same .so file of mine for the fault.
    So it's a bug in your code.
    Can it be due to some out-of-memory issue as am using Virtual machine?
    SIGSEGV doesn't mean out of memory. It indicates a bug in your code. Pointer problem. The register dump will tell you the pointer value.
  • 3. Re: Specific tags to be used for building library (.so) files in linux 64-bit?
    Sreram Newbie
    Currently Being Moderated
    Thanks for your replies.

    I read in many forums similar issues were caused by out-of-memory errors, and that is the reason why i was doubting my Virtual machine. I had my, now wrong, notion of out-of-memory confirmed when the issue didn't happen and was running fine in a normally installed linux 64-bit machine.

    However, while i were dealing with some other issue, I did find there was indeed a pointer issue, in the C code I use.

    The C code tries to close a hardware device connection. This code, sometimes, fails (I am currently working on how and when it fails). And this is where I experience another problem of not being able to open the device connection again.

    I now think both the issues are related to one another.

    Anyways any idea why the connection (opening and closing of device) might fail?

    Thanks for the help.
    Sreram
  • 4. Re: Specific tags to be used for building library (.so) files in linux 64-bit?
    EJP Guru
    Currently Being Moderated
    I read in many forums similar issues were caused by out-of-memory errors
    Only possible by ignoring zero malloc()/calloc()/realloc() results. Never seen one of those myself except in a deliberate torture test. Nothing to do with Java heap exhaustion either.
    Anyways any idea why the connection (opening and closing of device) might fail?
    You mean any idea why your unseen C code creates a pointer issue when opening or closing an unknown hardware device via an unknown API?

    No, not really.
  • 5. Re: Specific tags to be used for building library (.so) files in linux 64-bit?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Sreram wrote:
    I read in many forums similar issues were caused by out-of-memory errors,
    I seriously doubt you saw "many forums" in relation to a Java/JNI program which was caused by out of memory. That is because the error you posted is, in the vast majority of cases, caused by a pointer bug.
    Anyways any idea why the connection (opening and closing of device) might fail?
    Pointer bug. Standard problem in C/C++. It can cause all sorts of problems including any or all of the following (but not only these.)
    - Error you saw
    - No error at all
    - Error that occurs in code that has nothing to do with the code with the error.
    - Cause errors in the VM even though the VM is not the source of the problem.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points