Can low memory cause seg errors in native code?

Question

I have a group of crashes in my own code that are rare but occur sequentially with SEGV_MAPERR or SEGV_ACCERR. These crashes are almost always reported by Crashlytics with very low RAM (usually 1-5%). “Normal” crashes (i.e. those that I debugged) do not have a pattern in RAM.

Is it possible that these failures are caused by low memory? What will be the mechanism for this? Is there a way to tell if this is due to low memory errors or programming errors (using pointers incorrectly, etc.)? In many cases, an accident occurs in a library that I cannot debug, and I cannot replicate failures on my devices.

Here, some of these crashes are pulled from the Developer Console, as in these cases it contains a little more detail than 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

There are two common possibilities:

• The low memory condition alone is not going to somehow run segfault in a running application. What can happen is that when the application asks for additional memory, the memory allocation request is aborted. This is a well-defined memory condition. It has been documented that the corresponding system calls may fail during memory allocation. But it often happens that the application is incorrectly encoded to check an unsuccessful request for memory placement, and for this reason they fail. In this case, it is not true that the low memory condition is responsible for the application segfault, this is an application error.

• The Linux kernel reassigns available memory . As a result of this, it is possible that the kernel will have no choice but to choose the process to be killed when all available RAM has been exhausted.

However, in the case of the OOM killer, the selected victims end in SIGKILL . A SEGFAULT indicates an application error.