Happens only in 6.0 devices, the stack trace is as follows.
I'm scaling images down by setting BitmapFactory.Options.inSampleSize, so my code is scaling png files. What that be an issue?
backtrace:
#00 pc 000000000002c7d8 /system/lib64/libpng.so (sub_filter_2bpp_neon64+136)
#01 pc 0000000000012da4 /system/lib64/libpng.so (png_read_row+440)
#02 pc 0000000000013048 /system/lib64/libpng.so (png_read_rows+96)
#03 pc 000000000028c024 /system/lib64/libskia.so (_ZN17SkPNGImageDecoder8onDecodeEP8SkStreamP8SkBitmapN14SkImageDecoder4ModeE+1692)
#04 pc 000000000027f70c /system/lib64/libskia.so (_ZN14SkImageDecoder6decodeEP8SkStreamP8SkBitmap11SkColorTypeNS_4ModeE+152)
#05 pc 00000000000f6140 /system/lib64/libandroid_runtime.so
#06 pc 00000000000f6a78 /system/lib64/libandroid_runtime.so
#07 pc 0000000003497668 /system/framework/arm64/boot.oat
I got a Legacy project and after the first release some users started crashes. I spent three days searching. The problem was found very quickly when I got the problem device. As it turned out, I was looking at the wrong place because the project had many native libraries.
In my case, the problem was in the wrong PNG file in resources. This PNG was used for shadow in XML markup.
<View android:layout_width="fill_parent"
android:layout_height="8dp"
android:background="#drawable/df_tab_bar_shadow"/>
The picture was 16-bit colors. I converted PNG to 32-bit colors and the problem is solved
Related
the crash info is from bugly platform as below. I cannot discover the crash reason, or key info. Wish good ideas come here ~ Thanks.
#26968 RenderThread
SIGTRAP(TRAP_BRKPT)
error stack
stack
#00 pc 000000000337c958 /system/app/WebViewGoogle/WebViewGoogle.apk
#01 pc 000000000337c8c8 /system/app/WebViewGoogle/WebViewGoogle.apk
java:
I have a crash report for my app from Google Play services which looks like this:
backtrace:
#00 pc 00000000001b46a0 library.so
#01 pc 0000000000604464 library.so
#02 pc 0000000000c8ed1c library.so
I also have a .map file for library.so which helps me to locate function names and transform stacktrace into more readable format:
backtrace:
#00 pc 00000000001b46a0 library.so foo()
#01 pc 0000000000604464 library.so bar()
#02 pc 0000000000c8ed1c library.so zoo()
But manually resolving function names is error-prone and it doesn't give me the line numbers is source code which caused the crash.
I've considered an idea to store an unstripped version of library.so when publishing new version so that I could use ndk-stack tool, but AFAIK function addresses for stripped and unstripped binaries are differ.
So my question is it possible to continue publishing stripped binary and have means to automatically symbolize stack traces with line numbers?
Any suggestions will be greatly appreciated
ndk-stack is exactly built for this purpose, don't worry. You feed the unstripped library.so to it, and get the best stack trace you can achieve!
Make sure that you don't mix debug/releas versions, and keep the unstripped version for every binary that goes into production (or make sure that you can reliably rebuild such unstripped version for the corresponding git tag).
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
We've published an app in the Google Play store which has the possibility to show advertisements from Google DoubleClick for Publishers.
On certain advertisements the app crashes on the OnePlus 6. We do not get a stacktrace in our crash reporting, but do receive error logs in Google Play console as shown below. We are certain that it is being caused by ads, since it only appears on version which has ads. Also, the crash appears during the time the ad is being rendered.
The backtrace in Google Play shows the following log for every crash:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.myapp.app <<<
backtrace:
#00 pc 000000000076eb50 /vendor/lib/libllvm-glnext.so (ShaderObjects::loadProgramBinary(CompilerContext*, void*, unsigned int, QGLC_LINKPROGRAM_RESULT*)+855)
#01 pc 00000000006ddba5 /vendor/lib/libllvm-glnext.so (CompilerContext::loadProgramBinary(void*, unsigned int, QGLC_LINKPROGRAM_RESULT*)+108)
#02 pc 000000000077fb73 /vendor/lib/libllvm-glnext.so (QGLCLoadProgramBinary(void*, void*, unsigned int, QGLC_LINKPROGRAM_RESULT*)+54)
#03 pc 00000000001612b1 /vendor/lib/egl/libGLESv2_adreno.so (EsxShaderCompiler::LoadProgramBinaryBlob(EsxContext*, EsxProgram*, void const*, unsigned int, EsxInfoLog*)+164)
#04 pc 0000000000140191 /vendor/lib/egl/libGLESv2_adreno.so (EsxProgram::LoadProgramBinary(EsxContext*, unsigned int, void const*, int)+186)
#05 pc 00000000000aff67 /vendor/lib/egl/libGLESv2_adreno.so (EsxContext::GlProgramBinary(unsigned int, unsigned int, void const*, int)+230)
#06 pc 00000000000991d9 /vendor/lib/egl/libGLESv2_adreno.so (glProgramBinary+40)
#07 pc 0000000001748bff /data/app/com.android.chrome-2SPtcpkG5Ik-UldbIaNfyw==/base.apk
Locally we managed to reproduce this and got the following trace:
https://gist.github.com/Sammekl/66fc018f81a04d21717440924a206bdb
Does anyone know how to either fix or capture this crash? it's impacting a really large userbase right now.
I found the problem. It was caused by installing this app on top of the previous app. The previous app used some form of GPU caching in webviews which interferes with the new app.
The GPU caching was located in the internal storage location of the app:
data/data/com.sammekl.myapp/app_webview/GPUCache
I resolved this issue by recursively removing all files in this directory by using the Kotlin File extension function called deleteRecursively() during first time startup of the new app.
val gpuCache = File("${context.filesDir.parent}/app_webview/GPUCache")
gpuCache.deleteRecursively()
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?