JVM Crash 문제 해결하기

JVM Crash

JVM(Java virtual machine)은 Java 프로그램이 실행되는 가상 머신입니다. 하나의 VM이므로 내부에서 시그널을 주지 않으면 종료되지 않도록 디자인되어 있습니다. 반대로 PC에서 간혹 만나는 블루 스크린과 같이 이유를 알 수 없이 멈추기도 합니다. 이 경우를 JVM에서는 Crash라고 합니다.

JVM Crash는 발생 빈도가 낮고 원인 또한 작성한 애플리케이션에서 기인하지 않으므로 개발자들이 원인을 규명하기 어려워합니다. 그러나 PC에서 만나는 블루 스크린 화면에도 에러코드, 메모리 주소가 나오는 것처럼 JVM 또한 죽기 전 실마리를 떨구고 갑니다.

JVM도 애플리케이션입니다.

애플리케이션은 모든 버그에 있어 평등합니다. 일정 규모 이상의 모든 애플리케이션은 중요하거나 사소한 Bug를 가지고 있습니다.

JVM 도 당연히 Bug가 있습니다. 그리고 그 버그가 Crash를 만들기도 합니다. 애플리케이션의 문제로 JVM에 Crash가 발생하는 것도 JVM의 문제입니다. 이 경우에도 정상적인 JVM이라면 애플리케이션의 오류를 친절하게 Exception, Error로 알려주고 Crash 되는 일은 없어야 합니다. JVM이 알 수 없는 사유로 Crash 된다면 그건 JVM Bug입니다.

IBM JDK 8.0 Fix List 바로가기

다행인 것은 JDK 버그 픽스 리스트를 쉽게 찾아볼 수 있는 것입니다. IBM의 경우 유형별로 Crash, Hang, Performance 등으로 분류를 해 놓았습니다. 아래는 8.0 Fix Pack 리스트입니다. Defect Type을 보면 Crash, Issue, Hang 등으로 분류된 것을 볼 수 있습니다.

위 버그 수정 리스트에서 IJ11480: CRASH IN FFISYS CALL IN ZOS을 선택하면 아래와 같이 해당 버그에 대한 상세한 내용을 볼 수 있습니다.

물론 오라클에서도 버그 픽스 리스트를 관리하고 있습니다.

JVM이 죽기 전에 남긴 에러 로그 찾아내기

JVM이 비정상 종료되면 hs_err_pid (hotspot), javacore (IBM) 을 남기도록 되어 있습니다. 하지만 로그 생성되지 않았거나 찾지 못하는 경우 관련 환경 변수, 옵션 등을 적용해 반드시 로그가 남을 수 있도록 해야 합니다.

로그 파일이 생성되는 위치를 알수 없을 경우 아래와 같이 로그파일을 작성할 위치를 지정해 줍니다.

오라클의 경우 product flag를 사용합니다.

-XX:ErrorFile=/var/log/java/hs_err_pid%p.log

IBM의 경우 .profile 환경 변수를 사용합니다.

export IBM_JAVACOREDIR=/somewhere/dumpdir

그래도 로그가 남지 않는 경우라면 다음 상황을 의심할 수 있습니다.

• /tmp usage full : /tmp 파일시스템이 다 찼다면 로그가 기록되지 않습니다.
• 권한 문제 : java 프로세스를 구동 중인 계정이 대상 경로에 쓰기 권한이 없어도 로그가 기록되지 않습니다. 이 경우 JVM 옵션에 로그 경로를 설정합니다.
• JVM Bug : JVM Crash도 버그, Crash 로그를 기록하지 못하는 것도 결국 JVM Bug입니다. 원인 규명이 매우 어렵습니다.

에러로그 보는 법

아래는 Oracle hotspot hs_err_pid 내용입니다. 상단에는 발생 사유와 발생 위치가 있습니다.

여기서 SIGSEGV는 Segmentation fault를 의미하고 Crash의 발생 사유 입니다.

이외 대표적인 발생 사유로
• 사용자의 kill -3 로 발생된 SIGQUIT
• OOME(OutOfMemoryError) 로 발생된 Out of Memory Error
• StackOverFlow 로 발생한 StackOverFlow
등이 있습니다.

Problematic frame은 발생 위치를 나타냅니다.

위 예는 libjvm.so의 0x7c091b 위치에서 발생한 것으로 기록되어 있으므로 사용자가 구현한 영역의 오류가 아님을 알 수 있습니다.

같은 파일을 더 자세히 살펴보겠습니다.

Dump 내용을 확인해 보면, 0x7c091b는 Java Compiler 가 호출 한 Node인 것을 알 수 있습니다. Java bytecode를 기계어로 번역하는 과정에서 발생한 JVM 오류로 Crash가 발생했다고 판단할 수 있습니다.

IBM Java의 경우 javacore를 남깁니다. Oracle hotspot과 마찬가지로 상단에 발생 사유와 발생 위치가 있습니다.

발생 사유인 Dump Event "gpf"는 general protection fault이며 Segmentation fault와 동일합니다.

역시 아래에는 Module: /usr/java8_64/jre/lib/ppc64/compressedrefs/libj9thr29.so라는 발생 위치가 기록되어 있습니다.

구글에게 물어보기

크래시 원인이 SIGSEGV(Segmentation fault) 또는 gpf(general protection fault)이고 발생 위치가 JDK 내부 모듈이라면 JDK Fix를 통해 문제를 해결하면 됩니다.

오라클 Hotspot의 로그를 통해 libjvm.so의 0x7c091b에서 오류가 발생했다는 것을 확인했다면 이제 구글에서 해당 라인을 검색합니다.

검색을 하면 해당 라인의 버그를 확인해 볼 수 있습니다. 상태 값이 CLOSED입니다. 해당 버그 픽스를 찾으면 됩니다. https://bugs.openjdk.java.net/browse/JDK-8183197

하단에 Comments를 확인합니다. 버그 픽스에 대한 링크를 찾을 수 있습니다.

아래 링크에서 좀더 자세한 정보를 찾을 수 있습니다. https://bugzilla.redhat.com/show_bug.cgi?id=1306558

이제 해당 JDK 버전 이후의 Fix List를 검토하고 업데이트 계획을 세우면 됩니다. 다만 업데이트를 계획하는 대신 해당 버그의 원인을 기반으로 애플리케이션의 구조를 변경하여 문제를 회피하는 방법을 사용해 볼 수도 있습니다. 이런 경우 애플리케이션 성능 분석 도구가 도움이 될 수 있습니다.

마무리

JDK 역시 누군가 만든 애플리케이션입니다. JDK도 오류 가능성을 내포하고 있다는 것을 항상 인지하고 주기적인 업데이트를 통해 더 안정적인 환경을 만들어 나가야 합니다. 그리고 애플리케이션의 성능을 올려야 하거나 애플리케이션에서 발생한 문제가 해결되지 않는다면 와탭랩스([email protected])에 연락 주세요. 최대한 도와드리도록 하겠습니다.