This discussion is archived
9 Replies Latest reply: Feb 17, 2011 11:48 AM by jschellSomeoneStoleMyAlias RSS

JVM exit codes

840251 Newbie
Currently Being Moderated
We get several error messages and exit codes with an application that should import all files of a directory by a cron job (Linux, RHEL-5,x86_64,JDK-6u24). The method worked fine till an update 2 weeks ago but now it only reads some files and then it stops running and leaves the rest of the files untouched. Finally repeated starts of the program (50..100 times) will import all files and exits with a JVM-exit code of 0 but of course this is just a workaround.

Till now we saw two exit codes (130 and 139) that JVM is returning to the shell but we couldn't find a documentation what these codes mean.

Additionally we often (not always!) get a message from the cronjob like the following:

bin/runImport.sh: line 61: 5424 Speicherzugriffsfehler $JAVA_HOME/bin/java $JAVA_OPTS -cp $CP com.xyz.Import 2> ${LOGFILE}.tmperr >> $LOGFILE

Afterwards we find additional kernel-log-entries like the following one:

java[28544]: segfault at 000000004147bff8 rip 000000369c00de70 rsp 000000004147c000 error 6

PID and addresses change but "error 6" is constant. What means "error 6"?
  • 1. Re: JVM exit codes
    tschodt Pro
    Currently Being Moderated
    837248 wrote:
    java[28544]: segfault at 000000004147bff8 rip 000000369c00de70 rsp 000000004147c000 error 6

    PID and addresses change but "error 6" is constant. What means "error 6"?
    00000110 binary = 6 decimal
           . 0: no page found
          .  1: write
         .   1: user-mode
     40  * Page fault error code bits
     41  *      bit 0 == 0 means no page found, 1 means protection fault
     42  *      bit 1 == 0 means read, 1 means write
     43  *      bit 2 == 0 means kernel, 1 means user-mode
     44  *      bit 3 == 1 means use of reserved bit detected
     45  *      bit 4 == 1 means fault was an instruction fetch
  • 2. Re: JVM exit codes
    tschodt Pro
    Currently Being Moderated
    837248 wrote:
    Till now we saw two exit codes (130 and 139) that JVM is returning to the shell but we couldn't find a documentation what these codes mean.
    exit code 139 (128+11) is segmentation violation
    SIGSEGV is 11

    exit code 130 (128+2)
    SIGINT is 2
  • 3. Re: JVM exit codes
    840251 Newbie
    Currently Being Moderated
    Hm, you mean, all these error/exit codes are coming from the OS and not from JVM? Interesting and helpful,TNX!

    Meanwhile I checked the hardware, e.g. RAM which seems ok. - other JVMs on the same system don't show these errors and are running with the same JVM-version. So it seems to be an application bug although our developers say that the same application on Win- and OpenJDK-Java don't show these errors...
  • 4. Re: JVM exit codes
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    crefeld wrote:
    other JVMs on the same system don't show these errors and are running with the same JVM-version. So it seems to be an application bug
    That is not an absolute conclusion.

    Given that you have two apps (of any kind) A and B. Presumably A and B do different things. Because they do different things they are going to interact with the box in different ways. That is guaranteed.

    Thus if there is an OS problem or hardware problem application A can interact in such a way that it causes the problem where B doesn't do that. It could be using different memory, different accesses, completely different interactions with the OS.
    although our developers say that the same application on Win- and OpenJDK-Java don't show these errors...
    Which also doesn't mean much. The fact that java is supposed to be portable doesn't mean that it is an absolute. It could be that the latest update is only now exposing a bug in the VM which previous testing did not reveal. Since the VM targets a specific OS the fact that different VMs run without problem doesn't mean anything.
  • 5. Re: JVM exit codes
    tschodt Pro
    Currently Being Moderated
    crefeld wrote:
    Hm, you mean, all these error/exit codes are coming from the OS and not from JVM?
    If bit 2 had the value 0 that would indicate a kernel space (OS) segmentation violation
    but the value of bit 2 is 1 which indicates a user space segmentation violation.

    If you mean that the c code of the JVM is not deliberately calling
    exit(139);
    then, yes, it is not coming from the JVM.
  • 6. Re: JVM exit codes
    840251 Newbie
    Currently Being Moderated
    jschell wrote:
    crefeld wrote:
    other JVMs on the same system don't show these errors and are running with the same JVM-version. So it seems to be an application bug
    Given that you have two apps (of any kind) A and B. Presumably A and B do different things. Because they do different things they are going to interact with the box in different ways. That is guaranteed.

    Thus if there is an OS problem or hardware problem application A can interact in such a way that it causes the problem where B doesn't do that. It could be using different memory, different accesses, completely different interactions with the OS.
    Yes, generally speaking this seems to be possible, but it not very likely that a OS- or HW-error on a OS with up to 8 JVM being restarted every day one or more times, using -Xms smaller than -Xmx would give the "problem-JVM" always the same place in memory. And the segfaulting can get reproduced as long as we take the same bunch of files for importing and as long as this happens on the same OS and no matter whether the method is run within Tomcat or in a separated JVM (classes and libs are the same)..
    The Java-apps (most of them are running on Tomcat) are similar but there is some customizing which leads to slightly different applications - one of the reasons for why I think about an application bug.
  • 7. Re: JVM exit codes
    840251 Newbie
    Currently Being Moderated
    tschodt wrote:
    crefeld wrote:
    Hm, you mean, all these error/exit codes are coming from the OS and not from JVM?
    If bit 2 had the value 0 that would indicate a kernel space (OS) segmentation violation
    but the value of bit 2 is 1 which indicates a user space segmentation violation.
    Till today I thought that only segfaults in kernel space are recorded in the kernel log ("dmesg") but if these are segfaults in user space as you described, they obviously are logged in kernel log as well.
    If you mean that the c code of the JVM is not deliberately calling
    exit(139);
    then, yes, it is not coming from the JVM.
    This is what I meant. I didn't mention that we already checked that the code has no system-exit with a explicite setting of the exit-code.
  • 8. Re: JVM exit codes
    tschodt Pro
    Currently Being Moderated
    crefeld wrote:
    Afterwards we find additional kernel-log-entries like the following one:

    java[28544]: segfault at 000000004147bff8 rip 000000369c00de70 rsp 000000004147c000 error 6
    You should have hs_err_pid${PID}.log files then.
  • 9. Re: JVM exit codes
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    crefeld wrote:
    jschell wrote:
    crefeld wrote:
    other JVMs on the same system don't show these errors and are running with the same JVM-version. So it seems to be an application bug
    Given that you have two apps (of any kind) A and B. Presumably A and B do different things. Because they do different things they are going to interact with the box in different ways. That is guaranteed.

    Thus if there is an OS problem or hardware problem application A can interact in such a way that it causes the problem where B doesn't do that. It could be using different memory, different accesses, completely different interactions with the OS.
    Yes, generally speaking this seems to be possible, but it not very likely that a OS- or HW-error on a OS with up to 8 JVM being restarted every day one or more times, using -Xms smaller than -Xmx would give the "problem-JVM" always the same place in memory. And the segfaulting can get reproduced as long as we take the same bunch of files for importing and as long as this happens on the same OS and no matter whether the method is run within Tomcat or in a separated JVM (classes and libs are the same)..
    The Java-apps (most of them are running on Tomcat) are similar but there is some customizing which leads to slightly different applications - one of the reasons for why I think about an application bug.
    Your last statement contradicts the rest...

    Some bit of functionality could be interacting with the OS in such a way that causes the problem. No other app does it because no other app runs that bit of functionality.

    Also note that an exit with no other information would be a significant and very unusual error even for java code much less a VM.

    The only cases I can ever recall here on these forums (two I believe) turned out to be caused by an external application killing the VM.

    That said that very same bit of functionality that I mentioned above could be calling System.exit(). And that causes an exit.

Legend

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