5

I have a group of crashes in native code that are rare but happen consistently inolving SEGV_MAPERR or SEGV_ACCERR. These crashes are almost always reported by Crashlytics with very low RAM free (1-5% typically). 'Normal' crashes (ie, ones I have debugged) have no pattern in RAM free.

Is it possible these crashes are caused by a low memory condition? What would be the mechanism for this? Is there any way to tell if these are low memory related crashes or programming errors (using pointers wrongly, etc)? In many cases, the crash is happening in a library which I can't debug and I can't replicate the crashes on my devices.

Here's some of these crashes pulled from the Developer Console because it provides a little more detail than Crashlytics in the trace in these cases:

********** 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
Steve M
  • 9,296
  • 11
  • 49
  • 98
  • 1
    `SEG_MAPERR` typically results from a bad pointer operation (dereferencing a NULL, using a dangling pointer, falling off the end of an array, eetc). `SEG_ACCERR` tends to be associated with attempting to access memory without permission (e.g. writing to a read-only page). While low memory could increase the odds of such things happening, the root cause will be bad pointer operations in your code. – Peter Dec 26 '16 at 01:55

1 Answers1

7

There are two general possibilities:

  1. A low memory condition in of itself is not going to somehow trigger a segfault in a running application. What can happen is that when the application asks for additional memory to be allocated to it, the memory allocation request fails. This is a well defined memory condition. It is documented that the relevant system calls can fail in allocating memory. But what often happens is that the application are not coded properly to check for a failed memory allocation request, and they crash for that reason. In that case, it is not true that a low memory condition is responsible for an application segfault, it is an application bug.

  2. The Linux kernel overcommits the available memory. As a result of that it is possible that the kernel will have no option but to select a process to be killed, when all available RAM has been exhausted.

However, in the case of the OOM killer kicking in, the chosen victims are terminated with a SIGKILL. A SEGFAULT indicates an application bug.

Sam Varshavchik
  • 114,536
  • 5
  • 94
  • 148
  • Are you sure about #2 on Android. http://stackoverflow.com/questions/2567683/why-does-my-program-occasionally-segfault-when-out-of-memory-rather-than-throwin seems to say overcommits can cause SEGFAULT. – Steve M Dec 26 '16 at 02:22
  • It's `SIGKILL` [according to this first answer](http://stackoverflow.com/questions/6132333/how-to-detect-out-of-memory-segfaults). This makes sense. The goal here is to get rid of the process. `SIGSEGV` is catchable, and if caught, the signal would simply get rethrown when the signal handler returns. `SIGKILL` is not catchable, and is guaranteed to get rid of the process, which is the whole purpose here. – Sam Varshavchik Dec 26 '16 at 02:34
  • [Authoritative answer](https://www.kernel.org/doc/gorman/html/understand/understand016.html) - see section 13.4. It's `SIGKILL`. – Sam Varshavchik Dec 26 '16 at 02:37