分析JVM致命錯(cuò)誤日志hs_err_pid.log

當(dāng)jvm出現(xiàn)致命錯(cuò)誤時(shí)，會(huì)生成一個(gè)錯(cuò)誤文件?hs_err_pid<pid>.log，其中包括了導(dǎo)致jvm crash的重要信息，可以通過分析該文件定位到導(dǎo)致crash的根源，從而改善以保證系統(tǒng)穩(wěn)定。當(dāng)出現(xiàn)crash時(shí)，該文件默認(rèn)會(huì)生成到工作目錄下，然而可以通過jvm參數(shù)指定生成路徑

日志頭文件

日志頭文件包含概要信息，簡述了導(dǎo)致crash的原因。而導(dǎo)致crash的原因很多，常見的原因有jvm自身的bug，應(yīng)用程序錯(cuò)誤，jvm參數(shù)配置不當(dāng)，服務(wù)器資源不足，jni調(diào)用錯(cuò)誤等。

現(xiàn)在參考下如下描述：

?#
# A fatal error has been detected by the Java Runtime Environment:
#
# ?SIGSEGV (0xb) at pc=0x00007fb8b18fdc6c, pid=191899, tid=140417770411776
#
# JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J ?org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# ? http://bugreport.sun.com/bugreport/crash.jsp
#

由于項(xiàng)目在本地windows和linux直接運(yùn)行都是正常的并沒有報(bào)錯(cuò)，而使用docker運(yùn)行打包鏡像發(fā)布運(yùn)行就會(huì)報(bào)錯(cuò)。

解決方法:

jvm啟動(dòng)參數(shù)

再下面是jvm啟動(dòng)參數(shù)信息：

VM Arguments:
jvm_args: -Djava.util.logging.config.file=/home/service/tomcat7007-account-web/conf/logging.properties -Xmx4096m -Xms4096m -Xmn2560m -XX:SurvivorRatio=6 -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/home/work/webdata/logs/tomcat7007-account-web/develop/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/work/webdata/logs/tomcat7007-account-web/develop/ -Dtomcatlogdir=/home/work/webdata/logs/tomcat7007-account-web/develop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=7407 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.endorsed.dirs=/home/service/tomcat7007-account-web/endorsed -Dcatalina.base=/home/service/tomcat7007-account-web -Dcatalina.home=/home/service/tomcat7007-account-web -Djava.io.tmpdir=/home/service/tomcat7007-account-web/temp?
java_command: org.apache.catalina.startup.Bootstrap start
Launcher Type: SUN_STANDARD
?
Environment Variables:
JAVA_HOME=/home/service/jdk1.7.0_55
PATH=/opt/zabbix/bin:/opt/zabbix/sbin:/home/service/jdk1.7.0_55/bin:/home/work/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/work/bin
SHELL=/bin/bash

修改jvm啟動(dòng)參數(shù)-XX:+UseParallelGC -Xmx512m，看是不是內(nèi)存服務(wù)器分配內(nèi)存過小導(dǎo)致運(yùn)行直接崩潰。

如果改大參數(shù)之后還是報(bào)錯(cuò)，可能需要看javacv版本和OpenCV版本是否兼容，這里自己由于javacv內(nèi)部封裝全部OpenCV相關(guān)包太多，所以只使用剔除了一些不需要的依賴包從打包1個(gè)g直接變成100mb：

<dependency>
    <groupId>org.bytedeco</groupId>
    <artifactId>javacv</artifactId>
    <version>1.5.2</version>
</dependency>
<dependency>
    <groupId>org.bytedeco</groupId>
    <artifactId>javacpp</artifactId>
    <version>1.5.2</version>
</dependency>

<dependency>
    <groupId>org.bytedeco</groupId>
    <artifactId>opencv</artifactId>
    <version>4.1.2-1.5.2</version>
    <classifier>windows-x86_64</classifier>
</dependency>
<dependency>
    <groupId>org.bytedeco</groupId>
    <artifactId>openblas</artifactId>
    <version>0.3.7-1.5.2</version>
    <classifier>windows-x86_64</classifier>
</dependency>
<dependency>
    <groupId>org.bytedeco</groupId>
    <artifactId>ffmpeg</artifactId>
    <version>4.2.1-1.5.2</version>
    <classifier>windows-x86_64</classifier>
</dependency>


<dependency>
            <groupId>org.bytedeco</groupId>
            <artifactId>opencv</artifactId>
            <version>4.1.2-1.5.2</version>
            <classifier>linux-x86_64</classifier>
        </dependency>
        <dependency>
            <groupId>org.bytedeco</groupId>
            <artifactId>openblas</artifactId>
            <version>0.3.7-1.5.2</version>
            <classifier>linux-x86_64</classifier>
        </dependency>
        <dependency>
            <groupId>org.bytedeco</groupId>
            <artifactId>ffmpeg</artifactId>
            <version>4.2.1-1.5.2</version>
            <classifier>linux-x86_64</classifier>
        </dependency>

后邊去docker打包鏡像發(fā)布發(fā)現(xiàn)還是會(huì)報(bào)同樣的錯(cuò)誤，只能去看打包鏡像jdk版本了

發(fā)現(xiàn)由于docker打包鏡像使用的是基礎(chǔ)鏡像

FROM java:8-jre-alpine

因?yàn)檫@個(gè)基礎(chǔ)鏡像是基于Alpine的，但是javacv需要使用使用 glibc 的 OpenJDK 版本。

將版本替換成下面的版本就完美解決！?。?！

可以正常使用javacv去處理操作

openjdk:8u222-slim鏡像的jdk版本（可以）

# java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)

如果絕對需要使用該版本的 OpenJDK，則需要從不使用 glibc 的源代碼進(jìn)行重建（處理起來比較麻煩可能還會(huì)有別的一些問題產(chǎn)生）：
https://github.com/bytedeco/javacpp-預(yù)設(shè)/#build-instructions文章來源地址http://www.zghlxwxcb.cn/news/detail-770141.html

到了這里，關(guān)于docker環(huán)境javacv運(yùn)行時(shí)環(huán)境檢測到致命錯(cuò)誤：SIGSEGV(0xb)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！