I have integrated Huawei Crash Service as per documentation, and I am able to see NDK crashes in web console. However, the addresses in reports are offsetted by 4, so when I want to symbolicate crash, I get wrong result.
For example, in logcat I can see
2020-12-10 15:23:51.981 5914-5914/? D/formatEventInfo: statck
#00 pc 00c57c10 /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so(std::set_unexpected(void (*)())) [arm64-v8a::]
#01 pc 00c57d88 /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so(unknow) [arm64-v8a::]
#02 pc 00c54b54 /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so(unknow) [arm64-v8a::]
#03 pc 00c5425c /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so(__cxa_get_exception_ptr) [arm64-v8a::]
#04 pc 00c541dc /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so(unknow) [arm64-v8a::]
and that addresses appear in web console, while valid logcat crash stack trace is
--------- beginning of crash
2020-12-10 15:23:52.067 6246-6246/? I/crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
2020-12-10 15:23:52.068 871-871/? I//system/bin/tombstoned: received crash request for pid 5914
2020-12-10 15:23:52.069 6246-6246/? I/crash_dump64: performing dump of process 5914 (target tid = 5914)
2020-12-10 15:23:52.099 6246-6246/? A/DEBUG: pid: 5914, tid: 5914, name: o.a.b >>> package-name <<<
2020-12-10 15:23:52.104 6246-6246/? A/DEBUG: #01 pc 0000000000c57c0c /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so
2020-12-10 15:23:52.104 6246-6246/? A/DEBUG: #02 pc 0000000000c57d84 /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so
2020-12-10 15:23:52.104 6246-6246/? A/DEBUG: #03 pc 0000000000c54b50 /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so
2020-12-10 15:23:52.104 6246-6246/? A/DEBUG: #04 pc 0000000000c54258 /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so
2020-12-10 15:23:52.104 6246-6246/? A/DEBUG: #05 pc 0000000000c541d8 /data/app/package-name-w5yGIc9ek_yTyk1ARvNP-w==/lib/arm64/libName.so (__cxa_throw+120)
Any ideas?
The Crash Report you got is correct. Line numbers (00c57c10, 00c57c0c, etc) do not need to be exactly matched. Because an address segment is a range, for example, your 00c57c10 and the c57c0c are may in the same address of your file. If you upload the native symbol file, you may get a readable crash report.
Here you can see an example: Obtaining an NDK Crash Report
It seems you lost your uuid because of some mistakes of your files: [arm64-v8a::];[arm64-v8a::]... They should be with uuid.
Documentation of the AppGallery Connect Crash service
Related
I have a native executable that crash on start on x86_64 (API30) but runs fine on x86. Also runs fine on X86_64 API 21.
The first line of code in its entry point is:
printf("Starting");
Also tested this:
__android_log_print(ANDROID_LOG_WARN, TAG, "Starting");
Here is the dump when using log_print:
signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 0x0
#00 pc 0000000000009a24 /system/lib64/liblog.so (__android_log_level(char const*, unsigned long)+132) (BuildId: fe04dbc8d214fc65da81cacaf867b284)
#01 pc 0000000000009ec7 /system/lib64/liblog.so (__android_log_is_loggable+55) (BuildId: fe04dbc8d214fc65da81cacaf867b284)
#02 pc 0000000000007a27 /system/lib64/liblog.so (__android_log_print+135) (BuildId: fe04dbc8d214fc65da81cacaf867b284)
#03 pc 000000000009ca74 /data/app/~~XDpzR94g1TpiMQSCYqgNvA==/ccc71.at.free-SQEF9Jt3nPM0qDRUmW3P1Q==/lib/x86_64/liblib3c.so (entry_point+36) (BuildId: 6fa63521ac2c4be916d2aad9640a192de6db6ef3)
#04 pc 0000000000000001 <unknown>
Here is the dump when using printf():
backtrace:
#00 pc 00000000000c1cd0 /apex/com.android.runtime/lib64/bionic/libc.so (printf+112) (BuildId: 3707c39fc397eeaa328142d90b50a973)
#01 pc 000000000009ca88 /data/app/~~b68Ahj-zb4or4ECmKeyAhQ==/ccc71.at.free-v45ABuNSbmqW6dkOBadBZw==/lib/x86_64/liblib3c.so (entry_point+24) (BuildId: b80461f2139db953674f6a3eb7a0eefbe02b891e)
#02 pc 0000000000000001 <unknown>
The only particular setting I'm using at build time are this:
-DCMAKE_SHARED_LINKER_FLAGS=-shared -fPIC -Wl,-e,entry_point -Wl,--gc-sections
This allows the exe to be loaded as a library from the Java app and run as executable from shell. It works perfectly on arm 32/64 bits devices.
Any help in solving this would be appreciated.
We're investigating on an app developed by another team a native Crash on Android related to HereMaps (HERE SDK Navigation edition, navigate-4.10.2.0.7878) with this stacktrace:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.mydomain.myapp <<<
backtrace:
#00 pc 0000000000051010 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
#00 pc 0000000000e0143c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e0158c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e014f4 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e01478 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000debfe4 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000144cc84 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000014035bc /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000013fa668 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000155cff0 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000011273f8 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so (Java_com_here_sdk_navigation_VisualNavigator_disposeNativeHandle+480)
#00 pc 0000000000042020 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (art_jni_trampoline+96)
#00 pc 000000000020988c /apex/com.android.art/lib64/libart.so (nterp_helper+1948)
#00 pc 0000000000b6999c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator.access$000)
#00 pc 0000000000209124 /apex/com.android.art/lib64/libart.so (nterp_helper+52)
#00 pc 0000000000b69974 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.navigation.VisualNavigator$1.disposeNative)
#00 pc 0000000000073c6c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.odex (com.here.NativeBase$DisposableReference.dispose+156)
#00 pc 000000000020a0a0 /apex/com.android.art/lib64/libart.so (nterp_helper+4016)
#00 pc 00000000009a3834 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.cleanUpQueue+26)
#00 pc 0000000000209124 /apex/com.android.art/lib64/libart.so (nterp_helper+52)
#00 pc 00000000009a380e /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.access$100)
#00 pc 0000000000209124 /apex/com.android.art/lib64/libart.so (nterp_helper+52)
#00 pc 00000000009a37be /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>+22)
#00 pc 000000000020a044 /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
#00 pc 00000000009a37ca /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase$DisposableReference.<init>)
#00 pc 000000000020a748 /apex/com.android.art/lib64/libart.so (nterp_helper+5720)
#00 pc 00000000009a37fc /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.NativeBase.<init>+28)
#00 pc 000000000020a044 /apex/com.android.art/lib64/libart.so (nterp_helper+3924)
#00 pc 00000000009ac7f8 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/oat/arm64/base.vdex (com.here.sdk.core.threading.RunnableImpl.<init>+10)
#00 pc 00000000002cdd64 /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548)
#00 pc 00000000003d5660 /apex/com.android.art/lib64/libart.so (art::JNI<false>::CallNonvirtualVoidMethodV(_JNIEnv*, _jobject*, _jclass*, _jmethodID*, std::__va_list)+492)
#00 pc 00000000003d4ab4 /apex/com.android.art/lib64/libart.so (art::JNI<false>::NewObjectV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+736)
#00 pc 0000000000e0e858 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e37fac /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 0000000000e37a5c /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000140dad0 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000144c5e8 /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 000000000144d2bc /data/app/~~yFKezl3wu05hiNZ1aIFJIQ==/com.mydomain.myapp-sfkAGrmiHUTbEivXLD8EKQ==/base.apk!libheresdk.so
#00 pc 00000000000b2fd0 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+264)
#00 pc 0000000000052834 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
EDIT:
After some refactoring and cleaning operations in our code we've reached a clean condition in which we are confident that there aren't any leak; we've used LeakCanary to investigate and remove all these ones, but the native crash it's still here.
So we've tried to return back to basis and we've cloned HEREMaps Navigate Samples from github and we've found that in Navigation Sample there isn't any native crash, but there is also an only activity with heremaps instance references which die within the entire application.
To replicate a similar use case then our we've added an activity before the MainActivity of the Sample and we've tried to launch the activity and return back to the first one to show what is the behaviour of the library in terms of resources releasing.
Only opening and closing MainActivity from a starting one doesn't have any native crash also because VisualNavigator (which seems to be the class with native crash in the backtrace) is retained by it's delegates (aka Listeners) => setupListeners() in NavigationExample. So we've also removed all listeners when MainActivity calls onDestroy and in this way we see always the same native crash as in our app, going back from MainActivity to starting one.
Note: to be able to always reproduce the native crash we use LeakCanary because the library force GC when MainActivity has been destroyed; if we remove it the GC operation is done randomly by the system.
Links:
our version of HEREMaps Navigation SDK sample modified to reproduce native crash on github
video of crash of the sample: https://youtube.com/shorts/edY-TRvWh3I
So the big question here is: have we implemented wrong HEREMaps SDK integration (and managing instance releasing) or this native crash is inside the library and has to be fixed from the library owner?
Try find a way to make the VisualNavigator persistent:
Using StopRendering() is fine but do not null the VisualNavigator.
I had to go through the same issue when cancelling the route too quickly, although it got way worse over the recent updates and just crashes when just stopping navigation and this fixes it.
In the HERE SDK developer's guide there is a chapter that shows how to stop navigation. It is recommended to call stopRendering(). In your example app, it seems you do not call visualNavigator.stopRendering() when the intermediate activity gets destroyed. Try to call it.
In the developer options menu of the device you can turn on "Don't keep activities" to simulate such scenarios.
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.
my android crashes sometimes for some of the users which i am able to see google developer console.
Below is the crash log for the entire crash which i extracted out of google break pad. The crash clearly says that in the following function
js_cocos2dx_TextFieldTTF_textFieldWithPlaceHolder
but i am not able to uderstand as to why this is happening. I am currently using cocos2dx-js v 3.5.
Any help or idea as to why this crash happens would be highly useful.
Build fingerprint: 'motorola/falcon_bwaca/falcon_umts:4.4.4/KXB21.14-L1.50-1/1:user/release-keys'
pid: 30910, tid: 31705, name: Thread-6337 >>> in..test <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Stack frame #00 pc 00022160 /system/lib/libc.so (tgkill+12)
Stack frame #01 pc 000131b1 /system/lib/libc.so (pthread_kill+48)
Stack frame #02 pc 000133c5 /system/lib/libc.so (raise+10)
Stack frame #03 pc 000120fb /system/lib/libc.so
Stack frame #04 pc 00021a14 /system/lib/libc.so (abort+4)
Stack frame #05 pc 00c41251 libcocos2djs.so (__gnu_cxx::__verbose_terminate_handler()+228): Routine js_cocos2dx_TextFieldTTF_textFieldWithPlaceHolder(JSContext*, unsigned int, JS::Value*) at jsb_cocos2dx_auto.cpp:60716
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.