WebSphere Application Server & Liberty

Let's consider a Java program that makes a JNI call to the native (C) method that has a buggy code which terminates the program with a segmentation error. Complete details on how to execute the JNI program is illustrated here https://github.com/yathamravali/JNIDemo

#include "Crash.h"
#include "jni.h"
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
JNIEXPORT void JNICALL Java_Crash_printHello(JNIEnv *env, jobject obj){
        char *name=(char *)malloc(8);
        strcpy(name,"Ravali Yatham");
        return;
}

> java -Djava.library.path=. Crash
Unhandled exception
Type=Segmentation error vmState=0x00040000
J9Generic_Signal_Number=00000018 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
Handler1=00007F477C3AC7D0 Handler2=00007F4777B9F670 InaccessibleAddress=FFFFFFFFFFFFFFA0
RDI=0000000000000000 RSI=0000000000000000 RAX=FFFFFFFFFFFFFFA0 RBX=0000000000000010
RCX=00007F4778000020 RDX=5920696C61766152 R8=00007F47780008D0 R9=00007F477DEB0C40
R10=0000000000000000 R11=0000000000000000 R12=0000000000000000 R13=00007F477C47CCCC
R14=00007F477D30B700 R15=0000000000000000
RIP=00007F47606CC646 GS=0000 FS=0000 RSP=00007F477D30B400
Module=./libCrash.so
Module_base_address=00007F47606CC000 Symbol=Java_Crash_printHello
Symbol_address=00007F47606CC61A
Target=2_90_20191106_432135 (Linux 4.15.0-188-generic)
CPU=amd64 (4 logical CPUs) (0x1f27fd000 RAM)
----------- Stack Backtrace -----------
Java_Crash_printHello+0x2c (0x00007F47606CC646 [libCrash.so+0x646])
(0x00007F477C44E314 [libj9vm29.so+0x141314])
(0x00007F477C44BA37 [libj9vm29.so+0x13ea37])
(0x00007F477C339384 [libj9vm29.so+0x2c384])
(0x00007F477C326100 [libj9vm29.so+0x19100])
(0x00007F477C3E7A12 [libj9vm29.so+0xdaa12])
---------------------------------------

(gdb) f 13
#13 0x00007f47606cc646 in Java_Crash_printHello (env=0x17d4700, obj=0x18a1ee0) at Crash.c:8
8                strcpy(name,"Ravali Yatham");

(gdb) print name
$1 = 0xa0007f47780130e0 <error: Cannot access memory at address 0xa0007f47780130e0>

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 2
        at AIOBE.addStrings(AIOBE.java:3)
        at AIOBE.display(AIOBE.java:9)
        at AIOBE.main(AIOBE.java:13)

We're trying to access an element in the above code which is out of range, i.e we passed only 1 element at 0th index but we tried to fetch 3rd element which is at 2nd index. Hence, we caught an unexpected exception at Runtime as ArrayIndexOutOfBoundsException.

class Factorial {
  static int factorial(int n) {
    return (n * factorial(n-1));
    }    
  public static void main(String args[]){  
    int number=4;
    System.out.println("Factorial of "+number+" is: "+factorial(number));    
 }  
}  

Exception in thread "main" java.lang.StackOverflowError
        at Factorial.factorial(Factorial.java:3)
        at Factorial.factorial(Factorial.java:3)
        at Factorial.factorial(Factorial.java:3)
        at Factorial.factorial(Factorial.java:3)

if (n == 0 || n == 1)
            return 1;

• Make sure you are using the latest version of every product because there are often many code changes and bug fixes available.
• Make sure that the required settings for log collection are in place so that when an abnormal situation occurs all the logs are collected for diagnosis / root cause analysis.
• Make best use of exception handling. Wherever invoking APIs that are designed to throw, identify the right location to catch / absorb / mitigate the exception.
• There are common exceptions that are unavoidable (such as IOException / SocketException etc.) in a large application. Don't let those percolate further down the stack to become unhandled exceptions. A typical caller of APIs that throw IOException may retry a few times before abandoning the call.
• Don't ignore crashes by setting up scripts to clean up the dumps and re-spin your application. When we do this, we are potentially ignoring application / configuration / resource issues and making the application highly inefficient.
• Use JNI with caution. As most of the versatile JVM features around error detection will be missing in the JNI environment, faults occurring there will cause fatal errors to the application and the JVM.
• Calibrate your application with varying loads and identify the peak memory usage. Setup the heap limits accordingly, so as to avoid crashes due to Java heap exhaustion.
• Users might encounter crashes due to class cache corruption, clean the shared class cache and restart the application.
• If you encounter problems with the verifier turned off(-Xverify:none), remove this option and try to reproduce the problem.
• Make use of javacore information effectively. It is rich with data that represents the internal state of the virtual machine, and can help solve a great share of application anomalies that lead to crash.