Develop Reference

Crash maybe related to webview and chrome - signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

I have a crash happening at a few customers.
I have a couple of webview and the crash looks like related to chrome.
I see some bugs at bugs.chromium.org but I'm not sure how to handle this one?
I only have this stack trace:
backtrace:
#00 pc 000000000071270c /data/app/com.android.chrome-tF0yaJlYWnkgtHxT7MAlzg==/base.apk
#01 pc 00000000007124ec /data/app/com.android.chrome-tF0yaJlYWnkgtHxT7MAlzg==/base.apk

Can low memory cause seg faults in native code?

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

There are two general possibilities:
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.
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.

ndk-stack can not get full stack

I wrote a piece of code, in order to test the ndk-stack
Here is the code fragment
libtest.so
std::vector<int> testVec;
testVec.at(500);
But I get was incomplete stack
********** Crash dump: **********
Build fingerprint: 'MI/casablanca_icntv/casablanca:4.2.2/CADEV/1253:user/release-keys'
pid: 24989, tid: 24989 >>> com.ktcp.video <<<
signal 11 (SIGSEGV), fault addr deadbaad
Stack frame #00 pc 0001a852 /system/lib/libc.so: Routine ????:0
Stack frame #01 pc 00018190 /system/lib/libc.so (abort): Routine ????:0
Stack frame #00 pc 0001a852 /system/lib/libc.so: Routine ????:0
Stack frame #01 pc 00018190 /system/lib/libc.so (abort): Routine ????:0
Stack frame #00 pc 0001a852 /system/lib/libc.so: Routine ????:0
Stack frame #01 pc 00018190 /system/lib/libc.so (abort): Routine ????:0
Stack frame #00 pc 0001a852 /system/lib/libc.so: Routine ????:0
Stack frame #01 pc 00018190 /system/lib/libc.so (abort): Routine ????:0
^C^C
In the stack did not see my code, incomplete stack
How to fix it

0xdeadbaad was used by Bionic libc to indicate a deliberate abort. You can see a call to abort() on the fragment of stack you do get. I'm guessing you're triggering an assertion failure (which would show up in logcat).
On some versions of Android, in some circumstances, you don't get a good trace from abort(). Part of the problem is that the function was tagged with the noreturn attribute so the compiler wouldn't spit out complaints when you did something like this:
int foo(int x) {
if (x == 0) {
return 12345;
} else {
abort();
}
}
If abort() returned, this method would return an undefined value. On ARM, the return address lives in the LR register, and is preserved on the stack if necessary... but if the function doesn't return, then there's no need to save the return address, so the compiler is allowed to throw it away. This works out great until you want to have that address for the stack trace. If LR gets re-used, and the old value wasn't spilled to the stack, it's simply gone.
I think there might have been a release where the compiler issue was fixed, but some assembler meta-data was wrong, leading to similar trouble.
Recent versions of Android should not exhibit this behavior. Recent versions also replaced access to 0xdeadbaad with the more traditional SIGABRT, so you no longer see this particular crash signature.
(FWIW, you can see an attempted workaround for noreturn in 4.2.2 (see comments). It worked in earlier versions of the system.)

it says signal 11 (SIGSEGV), fault addr deadbaad, where 0xDeadBaad (dead, bad) is likely what is stored by default into uninitialized memory (it's an old pun). So it tries to read or execute uninitialized memory.

Android native application running even after segmentation fault with same PID

I'm running custom android on i.MX51 board and observed a strange issue with an application.
I got logs in n logcat of segmentation fault of an application (native, written using NDK) :
03-19 15:26:46.763 I/DEBUG ( 2234): pid: 2257, tid: 2257 >>> /usr/bin/powerMgr <<<
03-19 15:26:46.763 I/DEBUG ( 2234): signal 8 (SIGFPE), code 0 (?), fault addr 000008d1
Even after this the application continued to run with same PID (2257) which I confirmed from both logcat and ps command. Is this possible ? If yes, how ??

That's not a segmentation fault (SIGSEGV, signal 11). You got a SIGFPE, signal 8, possibly as the result of an integer divide-by-zero. The signal handling didn't kill the process, so it just continued executing.
Many ARM CPUs lack hardware division instructions, so the SIGFPEis thrown explicitly from the software divide function. As a result you don't get a meaningful value in "fault addr".
The treatment of this has changed over time; newer versions of Android are a bit better about it.

Android JNI: root-causing deadd00d (dvmAbort)

Comments on a number of StackOverflow questions have pointed out that a fault address of deadd00d indicates a deliberate VM abort.
I DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d
And indeed, when running the logs through ndk-stack, I see that the top of the stack frame decodes to:
Stack frame #00 pc 00050b0e /system/lib/libdvm.so (dvmAbort)
Then the comments say to look earlier in your logs for the problem. What exactly am I looking for -- is there a particular tag or string to search for? (dalvikvm perhaps?) I've scrolled through many pages of logs without finding anything relevant -- is that normal, or should it be immediately before the fault?
The deadd00d most frequently happens inside a particular call to GetObjectClass(). I've tried calling env->ExceptionCheck immediately before that line, but it doesn't report any prior errors.
I've also tried turning on CheckJNI with
adb shell setprop debug.checkjni 1
per the instructions here and here, but when killing and re-launching the app, I don't see the expected message
D Late-enabling CheckJNI
but rather
D AndroidRuntime: CheckJNI is OFF
Using adb shell getprop indicates that the property really is on, so I'm not sure what's going on there.

if it is native crash,you can search "backtrace"
it will point where you native code methods crash,than you should analyze the methods,