jvm 崩溃日志设置_JVM崩溃的原因及解决过程

最新推荐文章于 2024-06-25 12:56:35 发布

照月鱼yoyi

最新推荐文章于 2024-06-25 12:56:35 发布

阅读量1.2k

点赞数

文章标签： jvm 崩溃日志设置

本文链接：https://blog.csdn.net/weixin_32736623/article/details/111987968

版权

这篇博客介绍了在Java项目中遇到的一个由于JNI技术结合C++组件导致的崩溃问题。错误表现为EXCEPTION_ACCESS_VIOLATION，分析了错误日志，确定问题发生在JVM自身代码执行时，调用了MFC42.DLL。通过调整C++组件的使用方式，解决了内存泄露问题，从而避免了应用崩溃。

摘要由CSDN通过智能技术生成

前段时间有个项目，用到了JAVA和C++的JNI技术的结合，使用JAVA代码调用C++的组件的方法去获得该组件从其它接口得到的数据。在项目部署时，报错误如下：

# An unexpected error has been detected by HotSpot Virtual

Machine:

# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at

pc=0x73ed6e12, pid=5364, tid=5380

# Java VM: Java HotSpot(TM) Client VM (1.5.0_10-b03 mixed mode,

sharing)

# Problematic frame:

# C [MFC42.DLL+0x26e12]

--------------- T H R E A D ---------------

Current thread (0x035b1d50): JavaThread

"http-8080-Processor23" daemon [_thread_in_native, id=5380]

siginfo: ExceptionCode=0xc0000005, reading address

0x5678ec00

Registers:

EAX=0x5678ec00, EBX=0x73fb09f0, ECX=0x7ff82000,

EDX=0x73fb09f0

ESP=0x045bda0c, EBP=0x045bda30, ESI=0x73fb09e0,

EDI=0x5678ec00

EIP=0x73ed6e12, EFLAGS=0x00010206

Top of Stack: (sp=0x045bda0c)

0x045bda0c: 0000000c 045bda7c

045bda7c 00000000

0x045bda1c: 73fb09e0 045bda0c

045bda94 73f8e5a0

0x045bda2c: ffffffff 045bda44

73ed408f 045bda7c

0x045bda3c: 0000000c 000d98f4

045bda5c 73ed49ff

0x045bda4c: 0000000c 045bda64

77d03c10 00000004

0x045bda5c: 045bdaa0 10004a87

000d98f4 04a7acb0

0x045bda6c: 00000000 00000000

045bda88 03662350

0x045bda7c: 73fad5c4 045bda64

000d98f4 04ab5f28

Instructions: (pc=0x73ed6e12)

0x73ed6e02: 0c 89 10 8b 3e 89

46 0c 2b c7 49 75 f1 8b 7e 0c

0x73ed6e12: 8b 0f 53 89 4e 0c

ff 15 18 12 eb 73 8b 4d f4 8b

Stack: [0x04580000,0x045c0000), sp=0x045bda0c, free space=246k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,

C=native code)

C [MFC42.DLL+0x26e12]

C [MFC42.DLL+0x2408f]

C [MFC42.DLL+0x249ff]

C [UTScreen.dll+0x4a87]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM

code)

j com.crm.dbTransferConfig.util.bigScreenData.BigScreenDll.initTlib()Z+0

j com.crm.dbTransferConfig.util.bigScreenData.BigScreenDll.init()V+9

j com.crm.dbTransferConfig.util.bigScreenData.BigScreenDll.getInstanse()Lcom/crm/dbTransferConfig/util/bigScreenData/BigScreenDll;+35

j com.crm.dbTransferConfig.action.HuaanBigScreen.loadBigScreenDll()Ljava/lang/String;+3

v ~StubRoutines::call_stub

J sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;

J sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;

J sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;

J java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;

v ~RuntimeStub::alignment_frame_return Runtime1

stub

j com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(Ljava/lang/Object;Lcom/opensymphony/xwork2/config/entities/ActionConfig;)Ljava/lang/String;+177

j com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly()Ljava/lang/String;+14

j com.opensymphony.xwork2.DefaultActionInvocation.invoke()Ljava/lang/String;+89

j com.crm.platform.web.interceptor.LogIntercepter.intercept(Lcom/opensymphony/xwork2/ActionInvocation;)Ljava/lang/String;+34

j com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling()Ljava/lang/String;+15

j com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling()Ljava/lang/Object;+1