Question

我在本机代码中遇到了一组很少的崩溃，但这些崩溃很少发生在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

Answer 1

一般有两种可能性：

低内存条件本身不会以某种方式触发正在运行的应用程序中的段错误。可能发生的情况是，当应用程序要求为其分配额外的内存时，内存分配请求将失败。这是一个明确定义的内存条件。据记载，相关系统调用在分配内存时可能失败。但经常发生的是应用程序没有正确编码以检查失败的内存分配请求，并且由于这个原因它们崩溃了。在这种情况下，低内存条件不适用于应用程序段错误，这是一个应用程序错误。
Linux内核overcommits the available memory。因此，当所有可用的RAM都已耗尽时，内核可能无法选择要杀死的进程。

然而，在OOM杀手开始的情况下，选定的受害者将以SIGKILL终止。 SEGFAULT表示应用程序错误。

低内存可以导致本机代码中的seg错误吗？

1 个答案: