BUS_ADRERR在德洛彭（）

Question

在？我收到许多来自不同用户的此类崩溃报告。BUS_ADRERRdlopen()

一些注意事项：

1. 它发生在不同的库中（我们的应用程序使用一些）

2. si_addr加载库中信号点的地址。这真的让我感到困惑。

3. 始终有足够的系统内存可用。

4. 用户说应用程序将在第二次尝试时正确启动。

5. 我们的应用程序在加载库之前从ZIP中提取库。

6. 学习没有任何兴趣。journalctl

典型的崩溃报告（由 Java 生成）：

Stack: [0x00007f284919b000,0x00007f284939c000],  sp=0x00007f2849397258,  free space=2032k

Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)

C  [ld-linux-x86-64.so.2+0x1fa6f]

C  [ld-linux-x86-64.so.2+0x8ffc]

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

j  java.lang.ClassLoader$NativeLibrary.load0(Ljava/lang/String;Z)Z+0 java.base@10.0.1

j  java.lang.ClassLoader$NativeLibrary.load()Z+53 java.base@10.0.1

j  java.lang.ClassLoader$NativeLibrary.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)Z+216 java.base@10.0.1

j  java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+46 java.base@10.0.1

j  java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+48 java.base@10.0.1

j  java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+57 java.base@10.0.1

j  java.lang.System.load(Ljava/lang/String;)V+7 java.base@10.0.1

<snip>

siginfo: si_signo: 7 (SIGBUS), si_code: 2 (BUS_ADRERR), si_addr: 0x00007f27deec7880

<snip>

7f27dec43000-7f27decc1000 r-xp 00000000 08:08 1054117 <snip>/libswt-gtk-4922r22.so

7f27decc1000-7f27deec0000 ---p 0007e000 08:08 1054117 <snip>/libswt-gtk-4922r22.so

7f27deec0000-7f27deec8000 rw-p 0007d000 08:08 1054117 <snip>/libswt-gtk-4922r22.so

7f27deec8000-7f27deecb000 r-xp 00285000 08:08 1054117 <snip>/libswt-gtk-4922r22.so

<snip>

Memory: 4k page, physical 3902428k(1540768k free), swap 3998716k(3998716k free)

Answer 1

这在 Linux / x86 系统上非常罕见。SIGBUS发生这种情况的一种情况是当ed文件被截断时。从人地图：mmapSIGBUS&nbsp;Attempted&nbsp;access&nbsp;to&nbsp;a&nbsp;portion&nbsp;of&nbsp;the&nbsp;buffer&nbsp;that&nbsp;does&nbsp;not &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;correspond&nbsp;to&nbsp;the&nbsp;file&nbsp;(for&nbsp;example,&nbsp;beyond&nbsp;the&nbsp;end&nbsp;of&nbsp;the &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;file,&nbsp;including&nbsp;the&nbsp;case&nbsp;where&nbsp;another&nbsp;process&nbsp;has&nbsp;truncated &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;file).我们的应用程序在加载库之前从ZIP中提取库。一个疯狂的猜测：你有一个竞争条件，你可以同时从两个单独的线程执行这个提取。第一个线程从ZIP存档中提取，然后使用它。 ，重新定位它，然后调用库初始值设定项。libswt-gtk-4922r22.sodlopendlopenmmap当库初始值设定项正在运行时，第二个线程决定必须提取库（这是错误），并在将新的（相同的）内容写入文件之前截断该文件。一旦截断完成，第一个线程（仍在运行库初始值设定项）就会被 终止。.soSIGBUS通常的解决方法是确保在关键部分中完成“检查文件是否存在，如果不存在则提取”。