低内存会导致本机代码中的SEG故障

Question

我在本机代码中有一组崩溃，这些崩溃很少见，但会持续地侵蚀segv_maperr或segv_accerr。这些崩溃几乎总是由不含RAM的Crashlytics报告（通常为1-5％）。"正常"崩溃（即我已经调试的崩溃）没有免费的模式。

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

这是从开发人员控制台中抽出的其中一些崩溃，因为在这些情况下，它提供的详细信息比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

Answer 1

有两种一般可能性：

1. 本身的低记忆条件本身不会以某种方式触发运行应用程序中的segfault。可能发生的事情是，当应用程序要求将其他内存分配给它时，内存分配请求就会失败。这是一个明确定义的内存条件。据记录，相关的系统调用可能会在分配内存时失败。但是经常发生的是，该应用程序未正确编码以检查失败的内存分配请求，因此它们崩溃了。在那种情况下，低存储条件是为了应用程序segfault的原因，这是一个应用程序错误。

2. Linux内核超越了可用的内存。结果，当所有可用的RAM都用尽时，内核可能别无选择，只能选择要杀死的过程。

但是，在OOM杀手踢的情况下，选定的受害者被SIGKILL终止。SEGFAULT指示应用程序错误。