suddenly when opening my app i got one crash and i uploaded the crash log below.But it happens sometime only not every time and every device.
Can anyone help me to understand the crash log and why its happening for sometimes and some devices. what is main reason for the below crash?
Revision: '14'
ABI: 'arm'
pid: 1834, tid: 8022, name: pool-3-thread-1 >>> com.example <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/check_jni.cc:65] JNI DETECTED ERROR IN APPLICATION: java_array == null'
r0 00000000 r1 00001f56 r2 00000006 r3 00000000
r4 942bfdb8 r5 00000006 r6 00000002 r7 0000010c
r8 00000000 r9 b4e4f520 sl af17a800 fp 00000965
ip 00001f56 sp 942bf498 lr b6f26fd5 pc b6f4aeb4 cpsr 60070010
backtrace:
#00 pc 00037eb4 /system/lib/libc.so (tgkill+12)
#01 pc 00013fd1 /system/lib/libc.so (pthread_kill+52)
#02 pc 00014bef /system/lib/libc.so (raise+10)
#03 pc 00011531 /system/lib/libc.so (__libc_android_abort+36)
#04 pc 0000fcbc /system/lib/libc.so (abort+4)
#05 pc 0021d161 /system/lib/libart.so (art::Runtime::Abort()+160)
#06 pc 000a831b /system/lib/libart.so (art::LogMessage::~LogMessage()+1322)
#07 pc 000b1a49 /system/lib/libart.so (art::JniAbort(char const*, char const*)+1060)
#08 pc 000b1fa5 /system/lib/libart.so (art::JniAbortF(char const*, char const*, ...)+60)
#09 pc 001be127 /system/lib/libart.so (art::JNI::GetArrayLength(_JNIEnv*, _jarray*)+570)
#10 pc 00001171 /data/app/com.example-1/lib/arm/library.so (Java_com_example_value_encypt+48)
#11 pc 004986f9 /data/dalvik-cache/arm/data#app#com.example-1#base.apk#classes.dex
This kind of crash was happening to my app too. I could not figure it out through the logs. Once, I got hold of a device on which it crashed and found that it was crashing at a place where I was clearing the WebView cache. The problem was that the function to do that was deprecated, so in most of the phones it worked while in few others, it crashed. Since this was occurring probably even before Crashlytics got initialised, I was not getting any actual crash reports except from these kind of logs from Play Store.
What I would suggest is, check the device models from Play Store, and try to get a hold of one of these devices and try to see logcat crash report as it would point you to the actual problem.
Related
since December 2015, we are experiencing a strange crash only on a limited number of devices running Android 6.0 and 6.0.1. Most of them are Nexus 5.
First the log of the crash pulled from the Play Store. Looking int art_method.cc, it looks like the mapping of a certain method to native code fails. Maybe it is compilation induced?
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/hammerhead/hammerhead:6.0.1/MMB29Q/2480792:user/release-keys'
Revision: '0'
ABI: 'arm'
pid: 18737, tid: 18737, name: omittedapp >>> com.omitteddomain.omittedapp <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/art_method.cc:245] Failed to find native offset for dex pc 0x58 in android.view.View com.omitteddomain.omittedapp.PlotWidget.a(android.view.ViewGroup, android.view.LayoutInflater, java.util.List)'
r0 00000000 r1 00004931 r2 00000006 r3 b6f24b7c
r4 b6f24b84 r5 b6f24b34 r6 00000001 r7 0000010c
r8 b4c3f800 r9 b4c3de44 sl b361d3db fp b4c23450
ip 00000006 sp beb2ca90 lr b6c93b61 pc b6c95f50 cpsr 40070010
backtrace:
#00 pc 00041f50 /system/lib/libc.so (tgkill+12)
#01 pc 0003fb5d /system/lib/libc.so (pthread_kill+32)
#02 pc 0001c30f /system/lib/libc.so (raise+10)
#03 pc 000194c1 /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000174ac /system/lib/libc.so (abort+4)
#05 pc 00333971 /system/lib/libart.so (art::Runtime::Abort()+228)
#06 pc 000f45fb /system/lib/libart.so (art::LogMessage::~LogMessage()+2226)
#07 pc 000f08d1 /system/lib/libart.so (art::Barrier::~Barrier()+216)
#08 pc 0035b473 /system/lib/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+162)
#09 pc 00333a35 /system/lib/libart.so (art::Runtime::Abort()+424)
#10 pc 000f45fb /system/lib/libart.so (art::LogMessage::~LogMessage()+2226)
#11 pc 000ef88b /system/lib/libart.so (art::ArtMethod::ToNativeQuickPc(unsigned int, bool)+918)
#12 pc 00329055 /system/lib/libart.so (art::CatchBlockStackVisitor::VisitFrame()+180)
#13 pc 0033ccbd /system/lib/libart.so (art::StackVisitor::WalkStack(bool)+224)
#14 pc 0032910d /system/lib/libart.so (art::QuickExceptionHandler::FindCatch(art::mirror::Throwable*)+92)
#15 pc 0034a61d /system/lib/libart.so (art::Thread::QuickDeliverException()+140)
#16 pc 003fb7d9 /system/lib/libart.so (artThrowNullPointerExceptionFromCode+20)
#17 pc 00a15f01 /data/app/com.omitteddomain.omittedapp-1/oat/arm/base.odex (offset 0x59d000)
The only other occurrence of a similar crash (here Android ART: "Failed to find Dex offset for PC offset ...") has been reported to be potentially related to an infinite recursion issue. While we had an infinite recursion issue in the very same "a" method, it has been already fixed.
Some additional info:
The PlotWidget class in question display a chart to the user via a third party library. The cart view is configured inside the above "a" method. We changed the library multiple times with no difference in the outcome.
All of the third party libraries are up to date.
We have been able to test the app with the same data displayed to one of the afflicted user, without being able to reproduce the issue (being sensitive information, we were provided only the data strictly required to render the chart).
Attempts to reproduce the issue have failed with every combination of configuration/flavor, proguard enabled/disabled, zipalign yes/no, etc.
The app is compiled with Android Studio 1.5, with the latest SDK, targeting API 23. Before setting a lower target API and release an useless update for the umpteenth time, I'd like to know is someone experienced and solved similar issues.
Any advice is welcome.
Our app has millions of user, and we have encountered one wicked crash problem when we try to load our private so in a worker thread, about 0.01% of our users will crash during System.load().
Log like:
608dd000-608de000 r--p 00000000 b3:07 8514 /data/data/com.UCMobile/com/core/version.0/lib/libWebCore_UC.so
Thread Name: '<unregistered>'
pid: 16879, tid: 16947 >>> com.UCMobile <<<
signal 7 (SIGBUS), code 2 (BUS_ADRERR), fault addr 61e3eb64
r0 61e3eb64 r1 00000000 r2 00000480 r3 c0000000
r4 00000000 r5 00000000 r6 00000000 r7 00000000
r8 000e7094 r9 00000005 10 6110a000 fp 0000006b
ip 00000000 sp 60bec8c8 lr 00000000 pc 40062698 cpsr a0000010
#00 pc 40062698 /system/bin/linker
#01 pc 40061ce0 /system/bin/linker
#02 pc 4005fc22 /system/bin/linker
#03 pc 40060172 /system/bin/linker
#04 pc 400614fe /system/bin/linker
#05 pc 0006755c /system/lib/libdvm.so
#06 pc 00091f68 /system/lib/libdvm.so
#07 pc 000273a0 /system/lib/libdvm.so
#08 pc 0002b2dc /system/lib/libdvm.so
#09 pc 00084e44 /system/lib/libdvm.so
#10 pc 00093f98 /system/lib/libdvm.so
#11 pc 000273a0 /system/lib/libdvm.so
#12 pc 0002b2dc /system/lib/libdvm.so
#13 pc 00084a94 /system/lib/libdvm.so
#14 pc 00084b20 /system/lib/libdvm.so
#15 pc 000700f8 /system/lib/libdvm.so
#16 pc 0000e4a4 /system/lib/libc.so
>>> [Dalvik stack info] <<<
at java.lang.Runtime.nativeLoad(Native Method)
at java.lang.Runtime.load(Runtime.java:339)
at java.lang.System.load(System.java:500)
And when we looked into linker's code, we figured out the line of code where app crashed:
http://androidxref.com/4.4.4_r1/xref/bionic/linker/linker_phdr.cpp#348
bool ElfReader::LoadSegments() {
347 if ((phdr->p_flags & PF_W) != 0 && PAGE_OFFSET(seg_file_end) > 0) {
348 memset((void*)seg_file_end, 0, PAGE_SIZE - PAGE_OFFSET(seg_file_end)); --> crash when memset
349 }
350
In most cases, fault addr is equal to "seg_file_end". (We can verify it by the info of readelf -l libWebCore_UC.so.)
And if one user crashed like these, he will crash again and again. (some users crashed hundreds of times.)
And we have checked so's size before we loaded it, its size must be the same as we expect.
Most of these kind of crash is sigbus, sometimes is SIGSEGV.
Anyone has any idea about this?
Referring to code from the Linux kernel:
int filemap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
int error;
struct file *file = vma->vm_file;
struct address_space *mapping = file->f_mapping;
struct file_ra_state *ra = &file->f_ra;
struct inode *inode = mapping->host;
pgoff_t offset = vmf->pgoff;
struct page *page;
loff_t size;
int ret = 0;
size = round_up(i_size_read(inode), PAGE_SIZE);
if (offset >= size >> PAGE_SHIFT)
return VM_FAULT_SIGBUS;
...
/* Things didn't work out. Return zero to tell the mm layer so. */
shrink_readahead_size_eio(file, ra);
return VM_FAULT_SIGBUS;
}
It has two failure situations. One of them is that the file size is not large enough to cover the vma, the other is reading from filesystem has failed.
And you should ask me before posting this.
Some users of my game that are trying to play it in a Samsung Galaxy Note 4 updated to Android Lollipop 5.0 are experiencing a game crash at startup:
Build fingerprint: 'samsung/trlteuc/trlteatt:5.0.1/LRX22C/N910AUCU1COC2:user/release-keys'
Revision: '12'
ABI: 'arm'
pid: 20911, tid: 20927, name: GLThread 270611 >>> com.mangoprotocol.psychotic.mechanika <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
r0 00000000 r1 000051bf r2 00000006 r3 00000000
r4 b39ffdb8 r5 00000006 r6 00000002 r7 0000010c
r8 a0e1a140 r9 00000000 sl 00000001 fp aa934c40
ip 000051bf sp b39ff830 lr b6e8cff5 pc b6eb0998 cpsr 600b0010
backtrace:
#00 pc 00037998 /system/lib/libc.so (tgkill+12)
#01 pc 00013ff1 /system/lib/libc.so (pthread_kill+52)
#02 pc 00014c0f /system/lib/libc.so (raise+10)
#03 pc 00011531 /system/lib/libc.so (__libc_android_abort+36)
#04 pc 0000fcbc /system/lib/libc.so (abort+4)
#05 pc 00001259 /system/lib/libstdc++.so
#06 pc 00000afb /system/lib/libstdc++.so (__cxa_pure_virtual+6)
#07 pc 000e4595 /system/vendor/lib/egl/libGLESv2_adreno.so (EsxGlObject::DecRefCount(EsxContext*)+28)
#08 pc 000b4b67 /system/vendor/lib/egl/libGLESv2_adreno.so (EsxContext::GlUseProgram(unsigned int)+150)
#09 pc 000e02d3 /system/vendor/lib/egl/libGLESv2_adreno.so (EsxGlApiParamValidate::GlUseProgram(EsxDispatch*, unsigned int)+34)
#10 pc 000abd75 /system/vendor/lib/egl/libGLESv2_adreno.so (glUseProgram+44)
#11 pc 002e9887 /data/dalvik-cache/arm/data#app#com.mangoprotocol.psychotic.mechanika-1#base.apk#classes.dex
I don't know if this is related to the OpenGL ES driver for the GPU (Adreno 420) if it is a more general issue with the OS (Android Lollipop 5.0), or if it has something to do with libGDX (the game framework I'm using). What I know is that the games works like a charm in a Nexus 6 (also with Adreno 420) updated to Lollipop 5.1.
Do you have any idea about how to solve this issue or how to work around it?
Our company have an Android app that's been out for a few months now, where very few crashes have been reported.
But with Lollipop upgrades being rolled out to our customers devices, we got reports about intermittent Segmentation fault (SIGSEGV) crashes. And the crashes only occur on Android 5.0 devices - like upgraded Samsung Galaxy 5, Sony Xperia Z3, new HTC devices (unsure of model name) and a few other. All Android 4+ devices runs our app without problems, but all tested Android 5 devices so far get these crashes.
We have been able to reproduce them, in the sense that we on our own devices get these crashes. But we have so far been able to locate the source of the crashes, or find a pattern in what causes them.
This one of the reported crash dumps:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'samsung/klteactivexx/klteactive:5.0/LRX21T/xxxxxx:user/release-keys'
Revision: '8'
ABI: 'arm'
pid: 8779, tid: 10227, name: hwuiTask2 >>> com.ourcompany.ourapp <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbd04a008
r0 9d04a00c r1 b6f6b87c r2 9d04a000 r3 ffffffe2
r4 00000001 r5 07ffffff r6 00000002 r7 b6f6b894
r8 00000002 r9 fffffffc sl b6f6b87c fp 0000001f
ip 00000004 sp 9ee71a8c lr b6f37f4d pc b6f36a52 cpsr 00010030
backtrace:
#00 pc 0003ca52 /system/lib/libc.so (arena_run_reg_alloc+101)
#01 pc 0003df49 /system/lib/libc.so (je_arena_tcache_fill_small+96)
#02 pc 0004bad7 /system/lib/libc.so (je_tcache_alloc_small_hard+14)
#03 pc 000476af /system/lib/libc.so (je_malloc+302)
#04 pc 0000fa5f /system/lib/libc.so (malloc+10)
#05 pc 00000b09 /system/lib/libstdc++.so (operator new(unsigned int)+4)
#06 pc 000e2ecf /system/lib/libskia.so (SkPathRef::Editor::Editor(SkAutoTUnref<SkPathRef>*, int, int)+32)
#07 pc 000df1c1 /system/lib/libskia.so (SkPath::incReserve(unsigned int)+12)
#08 pc 000e0631 /system/lib/libskia.so (SkPath::addRRect(SkRRect const&, SkPath::Direction)+120)
#09 pc 000e0745 /system/lib/libskia.so (SkPath::addRoundRect(SkRect const&, float, float, SkPath::Direction)+76)
#10 pc 0003e6fd /system/lib/libhwui.so
#11 pc 0003e2ad /system/lib/libhwui.so
#12 pc 000314b3 /system/lib/libhwui.so
#13 pc 0001512b /system/lib/libhwui.so
#14 pc 0000ef11 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+112)
#15 pc 000602f5 /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+72)
#16 pc 0000ea81 /system/lib/libutils.so
#17 pc 000137bb /system/lib/libc.so (__pthread_start(void*)+30)
#18 pc 0001189b /system/lib/libc.so (__start_thread+6)
We have no native code in the app written by ourself, and the only libs we're using besides the Android libs are GSon 2.3.1, Ormlite 4.48 and Spring 1.0.0.
I'm a bit unsure how to proceed with these errors, so any help would be welcome. I have seen suggestions to use NDK Stack Tool to translate the crash dump to something more readable, but with no pre-existing knowledge about NDK, I have so far not been able to get it to work in my dev enviroment (Windows7, Eclipse Kepler.
Anyone who has any similiar experiences when Android 5.0 upgrades started to roll out to customers, or have any ideas on how or where I should continue to look for the cause?
I guess NDK Stack Tool is my best hope, but I have so far been unable to find a good tutorial that get's me anywhere with it.
Android Lolipop has an api that allows for easy transitions between shared elements in different activities.
Activity transitions
It looks like this api doesn't support a transition with multiple views. Is there a way to do this using the same api?
EDIT
Following the advice from #pskink I use a different method
ActivityOptions options = ActivityOptions
.makeSceneTransitionAnimation(this, Pair.create((View)view, "viewPager"), Pair.create((View) fab, "fab"));
startActivity(intent, options.toBundle());
This worked fine from ActivityA to ActivityB but hitting the back button results in this stacktrace
A/OpenGLRenderer(17305): requireSurface() called but no surface set!
A/libc(17305): Fatal signal 6 (SIGABRT), code -6 in tid 17349(RenderThread)
Build fingerprint: 'google/hammerhead/hammerhead:5.0/LRX21O/1570415:user/release-keys'
Revision: '11'
ABI: 'arm'
pid: 3364, tid: 3414, name: RenderThread >>> com.example.package <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'requireSurface() called but no surface set!'
r0 00000000 r1 00000d56 r2 00000006 r3 00000000
r4 9e9b5db8 r5 00000006 r6 0000003e r7 0000010c
r8 ac39bacc r9 9e9b5d08 sl 9e9b5d00 fp ac39bb08
ip 00000d56 sp 9e9b5858 lr b6f1faf9 pc b6f435d4 cpsr 600f0010
backtrace:
#00 pc 0003a5d4 /system/lib/libc.so (tgkill+12)
#01 pc 00016af5 /system/lib/libc.so (pthread_kill+52)
#02 pc 00017707 /system/lib/libc.so (raise+10)
#03 pc 00013f75 /system/lib/libc.so (__libc_android_abort+36)
#04 pc 00012a3c /system/lib/libc.so (abort+4)
#05 pc 00007a59 /system/lib/libcutils.so (__android_log_assert+88)
#06 pc 0003b61f /system/lib/libhwui.so
#07 pc 0003b971 /system/lib/libhwui.so
#08 pc 0003cf8d /system/lib/libhwui.so
#09 pc 0003cea5 /system/lib/libhwui.so
#10 pc 0003d885 /system/lib/libhwui.so
#11 pc 0003e27b /system/lib/libhwui.so (android::uirenderer::renderthread::RenderThread::threadLoop()+66)
#12 pc 000104d5 /system/lib/libutils.so (android::Thread::_threadLoop(void*)+112)
#13 pc 0005df4d /system/lib/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+72)
#14 pc 00010045 /system/lib/libutils.so
#15 pc 000162e3 /system/lib/libc.so (__pthread_start(void*)+30)
#16 pc 000142d3 /system/lib/libc.so (__start_thread+6)
EDIT2
The only logs that I receive when I filter by package name are below. The first log looks like it is coming from render script, I posted the log above as I thought it is related.
A/OpenGLRenderer(11128): requireSurface() called but no surface set!
A/libc(11128): Fatal signal 6 (SIGABRT), code -6 in tid 11219
(RenderThread)
I/ci(11358): Making Creator dynamically
W/ResourcesManager(11358): Asset path
'/system/framework/com.android.media.remotedisplay.jar' does not exist
or contains no
W/ResourcesManager(11358): Asset path
'/system/framework/com.android.location.provider.jar' does not exist
or contains no
EDIT3
So I was able to get this to work by disabling the mapfragment that was on activityA. I am still investigating why this would happen