5

我在本机代码中有一组很少见的崩溃，但在涉及 SEGV_MAPERR 或 SEGV_ACCERR 时一直发生。这些崩溃几乎总是由 Crashlytics 报告，其可用 RAM 非常低（通常为 1-5%）。“正常”崩溃（即我调试过的）在可用 RAM 中没有模式。

这些崩溃是否可能是由内存不足引起的？这将是什么机制？有什么方法可以判断这些是否与内存不足相关的崩溃或编程错误（错误地使用指针等）？在许多情况下，崩溃发生在我无法调试的库中，我无法在我的设备上复制崩溃。

以下是从开发人员控制台中提取的一些崩溃，因为在这些情况下，它在跟踪中提供了比 Crashlytics 更多的详细信息：

********** Crash dump: **********
Build fingerprint: 'htc/a32eul_metropcs_us/htc_a32eul:5.1/LMY47O/637541.3:user/release-keys'
pid: 10902, tid: 10989, name: .xxx.xxxx  >>> com.xxx.xxxxx <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x97f78000
Stack frame #00 pc 0004cd80  /data/app/xxx.xxx.xxxxx-1/lib/arm/libxxx.so: Routine xxxxxMixerInterleavedFloatOutput at libgcc2.c:?

********** Crash dump: **********
Build fingerprint: 'Xiaomi/land/land:6.0.1/MMB29M/V8.1.1.0.MALMIDI:user/release-keys'
pid: 2661, tid: 2746, name: .xxx.xxxx  >>> com.xxx.xxxx <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Stack frame #00 pc 00016954  /system/lib/libc.so (__memcpy_base+36)
Stack frame #01 pc 0000b14c  /data/app/com.xxx.xxxx-2/lib/arm/libswresample-2.so: Routine ??
??:0
4

1 回答 1

7

一般有两种可能：

  1. 内存不足的情况本身不会以某种方式触发正在运行的应用程序中的段错误。可能发生的情况是，当应用程序要求为其分配额外的内存时，内存分配请求会失败。这是一个定义明确的记忆条件。据记载，相关系统调用在分配内存时可能会失败。但是经常发生的情况是应用程序没有正确编码以检查失败的内存分配请求，并且因此而崩溃。在这种情况下，内存不足的情况不是导致应用程序段错误的原因，而是应用程序错误。

  2. Linux 内核过度使用可用内存。因此，当所有可用 RAM 已用尽时，内核可能别无选择，只能选择要杀死的进程。

但是，在 OOM 杀手介入的情况下，选定的受害者会以SIGKILL. ASEGFAULT表示应用程序错误。

于 2016-12-26T01:53:11.043 回答