Develop Reference

tgkill - native error on Android 8.0 Samsung S8

Recently I started getting Android native crashes (reported in Google Play vitals). They happen only on Samsung Galaxy S8 or S8+ phones with Android 8.
According to the stack trace it is related to the UI renderer thread. However I don't know how to fix it or even where exactly in the app does it happen.
Any idea how to find out where in the app does this happen? And why only Galaxy S8 with Android 8 are affected? Thanks.
backtrace:
#00 pc 0000000000071854 /system/lib64/libc.so (tgkill+8)
#01 pc 000000000001e058 /system/lib64/libc.so (abort+88)
#02 pc 0000000000008248 /system/lib64/liblog.so (__android_log_assert+328)
#03 pc 0000000000052430 /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread10EglManager11damageFrameERKNS1_5FrameERK6SkRect+320)
#04 pc 000000000004f9dc /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread14OpenGLPipeline4drawERKNS1_5FrameERK6SkRectS8_RKNS0_12FrameBuilder13LightGeometryEPNS0_16LayerUpdateQueueERKNS0_4RectEbRKNS0_15BakedOpRenderer9LightInfoERKNSt3__16vectorINS_2spINS0_10RenderNodeEEENSM_9allocatorISQ_EEEEPNS0_19FrameInfoVisualizerE+76)
#05 pc 000000000004d7e0 /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread13CanvasContext4drawEv+176)
#06 pc 00000000000511e8 /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread13DrawFrameTask3runEv+184)
#07 pc 0000000000058494 /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+356)
#08 pc 0000000000011c58 /system/lib64/libutils.so (_ZN7android6Thread11_threadLoopEPv+280)
#09 pc 00000000000fd688 /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+136)
#10 pc 000000000006de44 /system/lib64/libc.so (_ZL15__pthread_startPv+36)
#11 pc 000000000001f9a4 /system/lib64/libc.so (__start_thread+68)

Logcat analysis
This is where your code is crashing EglManager.cpp:
void EglManager::damageFrame(const Frame& frame, const SkRect& dirty) {
#ifdef EGL_KHR_partial_update
if (EglExtensions.setDamage && mSwapBehavior == SwapBehavior::BufferAge) {
EGLint rects[4];
frame.map(dirty, rects);
if (!eglSetDamageRegionKHR(mEglDisplay, frame.mSurface, rects, 1)) {
LOG_ALWAYS_FATAL("Failed to set damage region on surface %p, error=%s",
(void*)frame.mSurface, egl_error_str());
}
}
#endif
}
Called from SkiaOpenGLPipeline.cpp:
SkiaOpenGLPipeline::draw //method
mEglManager.damageFrame(frame, dirty);
Why ?
It seems you may have a 'Failed to set damage region on surface', probably after onResume() from screen rotation or onPause() in your Activity. See fixing-common-android-lifecycle-issues
Fixes
I started getting this crash after updating to Oreo, every-time I
started my app, with the message "Failed to set damage region on
surface" followed by all those lines about libhwui.so and EglManager
And it turned out that, for some obscure reason, it was somehow caused
by a totally unrelated problem in my app (too many open files [forgot
to close them]). After fixing this my own bug, no more crashes on the
EglManager. [also note that crashes only happen if hardware
acceleration is turned on] Ref: issuetracker.google.com { issue 70259031}
See also: eglCreateWindowSurface {SO problem}, Logging, native-crashes-on-abort-in-developer-console-with-oreo-8-1 {SO problem}, hardware-acceleration, opengl, GLSurfaceView

This problem seems to be restricted to Samsung devices with Android 8.0, it is some bug about text selection and/or entering text and/or closing a dialog containing EditTexts and/or rotating the screen.
It seems that there is a workaround. Create a xml file in the res/drawable folder defining an empty shape, as follows.
<?xml version="1.0" encoding="utf-8"?>
<shape xmlns:android="http://schemas.android.com/apk/res/android" android:shape="rectangle" >
<!-- nothing -->
</shape>
In the layout file, add the following attributes to the EditTexts:
android:textSelectHandle="#drawable/empty"
android:textSelectHandleRight="#drawable/empty"
android:textSelectHandleLeft="#drawable/empty"
source: Samsung developers forum crash Samsung Galaxy S8 libhwui.so

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

native crash points to deleted libcrashreport.so

Sometimes I come across crash reports that look quite similar to this one: http://en.miui.com/thread-663538-1-1.html.
In particular, note this:
backtrace:
#00 pc 00000408 /data/data/com.XXXX.YYY/files/libcrashreport.so (deleted) (offset 0x7000)
#01 pc 00091add /system/lib/libart.so (offset 0x1cf000)
It seems to happen on some Android 7 builds. The specific offset in libart.so may be different, so is the offset in libcrashreport.so. But I could not find any mention of libcrashreport in the Android sources. And what would (deleted) mean? The APK does not ship with such library.
PS: Could this library be part of Apptimize SDK?

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.

Google Developer Console Crash Reading for cocos2dx crashes

I have some stack traces in my Crash Tab in Developer Console, I was wondering how to read and debug them. The code is in cocos2dx so its really not human readable.
I know the technique with the ndk-stack where it tell you the class and line number etc. but can it be applicable in this scenario since I don't have the obj/local/armeabi folder with me.
adb logcat | ndk-stack -sym ./obj/local/armeabi is the command which I am talking about.
Is there any other solution to solve this problem, so that I can see what crashes users are experiencing.
Thank you.
A stack trace from the application. How can we trace this? And its crashing on just one device. Galaxy Tab 3 10.1 with such logs.
Build fingerprint:
'samsung/santos103gxx/santos103g:4.2.2/JDQ39/P5200XXUANC1:user/release-keys'
pid: 11321, tid: 11321, name: ldhelloworld >>> com.test.helloworld
<<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000005
Stack frame #00 pc 0002b098 Stack frame #01 pc 00000020
Crash dump is completed