I'm trying to debug a mysterious crash of my Android application that seems to occur in the low memory conditions. The sources of the app in question are available from https://bitbucket.org/stativ/chmupocasi. The application's package is cz.jirkovsky.lukas.chmupocasi
What happens is that when the phone starts to run low on memory and I try to reopen the application from the list of recent apps (the one that shows after a long press of the Home button), the application crashes.
I've tried to debug the application using the Android Studio, but the application always crashes before hitting any of the breakpoints in the main Activity's onCreate() and onStart() making it impossible to debug. What is worse that even the logcat doesn't contain any information, the only related line shown when the app crashes is:
I/ActivityManager( 428): Displayed cz.jirkovsky.lukas.chmupocasi/.MainActivity: +1s45ms (total +23m23s835ms)
The full logcat is available at http://pastebin.com/TtSuqxCW, in case I'm missing something.
Finally, I've tried attaching the debugger to the application after it crashes, when the Android's dialog "Unfortunately the application has stopped" is shown. I don't see any of my code being run in any thread. Here is what the "Export Threads" contain:
<1> main#830017304224, prio=5, in group 'main', status: 'RUNNING'
at android.os.BinderProxy.transact(Binder.java:-1)
at android.app.ActivityManagerProxy.handleApplicationCrash(ActivityManagerNative.java:3147)
at com.android.internal.os.RuntimeInit$UncaughtHandler.uncaughtException(RuntimeInit.java:76)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)
at dalvik.system.NativeStart.main(NativeStart.java:-1)
<10> Binder_2#830026133152, prio=5, in group 'main', status: 'RUNNING'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<9> Binder_1#830026131496, prio=5, in group 'main', status: 'RUNNING'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<8> FinalizerWatchdogDaemon#830026116408 daemon, prio=5, in group 'system', status: 'WAIT'
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:364)
at java.lang.Daemons$FinalizerWatchdogDaemon.run(Daemons.java:214)
at java.lang.Thread.run(Thread.java:856)
<7> FinalizerDaemon#830026115976 daemon, prio=5, in group 'system', status: 'WAIT'
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:401)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:102)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:73)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:169)
at java.lang.Thread.run(Thread.java:856)
<6> ReferenceQueueDaemon#830026115560 daemon, prio=5, in group 'system', status: 'WAIT'
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:364)
at java.lang.Daemons$ReferenceQueueDaemon.run(Daemons.java:129)
at java.lang.Thread.run(Thread.java:856)
<5> Compiler#830026115320 daemon, prio=5, in group 'system', status: 'WAIT'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<3> Signal Catcher#830026114840 daemon, prio=5, in group 'system', status: 'WAIT'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<2> GC#830026114616 daemon, prio=5, in group 'system', status: 'WAIT'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
If I try to examine the main thread, I can see that there is an unhandled exception somewhere in the ThreadGroup:
No such instance field: 'nthreads'
Any ideas how to debug such crash or how to get more information about it?
I've finally found a solution. It was actually two separate problems.
The first one was that my device (Huawei Y300) didn't log any stack trace that could be retrieved using logcat. This was likely resolved by a reboot that i did earlier today, or, less likely, by the fact that I tried to use logging via android.util.Log to log some debug info.
The second one was the crash itself. After getting the stack trace from the crash, the problem was quite easy to fix. Even though the previous information I obtained using debugger pointed to some problem with threads, the real cause was the following exception:
android.app.Fragment$InstantiationException: Unable to instantiate fragment cz.jirkovsky.lukas.chmupocasi.RetainFragment: make sure class name exists, is public, and has an empty constructor that is public
The true cause was that the RetainFragment was package private. However, all classes inheriting from Fragment have to be public classes or public static inner classes.
If they are not, it may bite you badly. The reason is that even though it seems to work fine when the class is package private, it will fail when a Fragment is being recreated after it was destroyed to reclaim some memory in a low mem condition.
The moral at the end is that you shouldn't always listen to what your IDE says, because I introduced the bug after the Android Studio told me that this fragment class can be made package private.
Related
I have suddenly hit a wall with testing my Xamarin.Forms app. IT has suddenly started throwing the two messages below and failing (on my Android Emulator) immediately after the splash screen disappears.
I get the following warning during the build:
Ignoring C:\Users\geral\.nuget\packages\system.security.cryptography.cng\4.3.0\ref\netstandard1.6\System.Security.Cryptography.Cng.dll as it is a Reference Assembly
And then the Output windows shows these message when the app fails:
11-18 09:33:29.257 D/Mono (31723): Assembly Ref addref Xamarin.GooglePlayServices.Tasks[0xe1503180] -> Mono.Android[0xe15031e0]: 26
11-18 09:33:29.260 D/Mono (31723): Assembly Loader probing location: 'System.Security.Cryptography.Cng'.
11-18 09:33:29.260 F/monodroid-assembly(31723): Could not load assembly 'System.Security.Cryptography.Cng' during startup registration.
11-18 09:33:29.260 F/monodroid-assembly(31723): This might be due to an invalid debug installation.
11-18 09:33:29.260 F/monodroid-assembly(31723): A common cause is to 'adb install' the app directly instead of doing from the IDE.
In searching the web, I found a few articles that seemed related but nothing fixes the error. I have updated all NuGet packages and the Android SDK to the latest available. I am out of ideas.
https://forums.xamarin.com/discussion/63584/android-could-not-load-assembly-xxx-during-startup-registration
https://forums.xamarin.com/discussion/42405/debug-deployment-to-device-works-fine-release-fails-with-odd-messages-anybody-have-a-fix-for-this
Anyone have additional suggestions?
The actual answer was a little obvious after I had some time to come back to it. I added the NuGet package directly to my projects and now things are working correctly again. I had assumed the Reference would be sufficient, but in this case a direct reference was apparently needed. Still not sure why, or what changed that made it suddenly become a problem.
But if you get these message in the future try adding the package directly.
I am trying to find memory leaks and corruptions in my native code, which is part of a sample java app. Since the procedure for using malloc debug has been updated from Nougat onwards (ref: Malloc Debug for Android N), I have followed the steps in that page to set the options of my interest.
Fortunately, I was able to get the mem corruption detection work (by use of guard option) for a simple buffer overflow in my native code. But, whatever option I use, I couldn't get the leaks detected.
I tried these options:
adb shell setprop libc.debug.malloc.options backtrace
adb shell setprop libc.debug.malloc.options leak_track
I also tried a combination of both options. I didnt see any mallocs or leaks present in my code being captured in logcat. In fact, for most devices I see that device is stuck in bootup when 'backtrace' option is set.
However, what I see is in the logs, is apparently false-positives for leaks in lot of other system programs:
12-16 13:05:51.908 8396 8396 E malloc_debug: +++ chmod leaked block of size 152 at 0x7f7de4b0e0 (leak 1 of 19)
...
12-16 13:05:52.156 8423 8423 E malloc_debug: +++ chown leaked block of size 152 at 0x7f8384b0e0 (leak 1 of 26)
...
12-16 13:05:56.533 8845 8845 E malloc_debug: +++ getprop leaked block of size 152 at 0x7fb684b0e0 (leak 1 of 17)
...
12-16 13:07:24.036 12393 12393 E malloc_debug: +++ /system/bin/dex2oat leaked block of size 131072 at 0xeb22c010 (leak 1 of 2452)
...
12-16 13:07:49.192 13734 13734 E malloc_debug: +++ logcat leaked block of size 5176 at 0x7f8dc5f020 (leak 1 of 21)
So, I have two questions in this context:
Does my apk need to be in a specific location for backtrace/leak_track to work? Was it ever tested for apks before, at least on N?
Do I need to set any other option for leak detection to work?
It looks like Malloc debug on Nougat is not explored much, so I didnt see any results on Google for any known issues or restrictions.
More details on my setup:
- Android Nougat 7.0
- 64 bit chipset
- Java sample app, with native code as shared lib
I'm using Android Studio to debug a NativeActivity app written in C++
In my C++ code the first thing I do in android_main() is wait 10 seconds for the debugger to attach. In the 'Debug' window I see:
Now Launching Native Debug Session
and then after a few seconds
Debugger attached to process 28458
and then right after it attaches, the debugger is stopped with a signal:
Signal: 33 (signal SIG33)
I press 'Resume Program' and then I get the same signal again and again for 7-8 times. After that, the program continues as expected, debugger attached and I am able to stop it at breakpoints.
What's the meaning of that SIG33? how can I prevent it?
Signal 33 is used internally by bionic for the backtrace facilities.
See comment in __libc_current_sigrtmin.cpp.
// POSIX timers use __SIGRTMIN + 0.
// libbacktrace uses __SIGRTMIN + 1.
// libcore uses __SIGRTMIN + 2.
See definition of __SIGRTMIN for generic, arm, x86, and mips.
#define __SIGRTMIN 32
I think that SIG33 is caused by gdb and gdb is not correctly ignoring it.
Those can be ignored and/or silenced using below GDB command-line:
handle SIG33 nostop noprint
SIG33 is used to signal about "threading libraries" by LLDB.
Excerpt from LLDB source:
AddSignal (33, "SIG33", false, false, false, "threading library internal signal 2");
But I don't seem to understand the reason why your code is getting this. May be due to some minor dependency issues.
Dose "aapt.exe" write a log file, and if so, how does one view it?
Starting this morning I began getting messages that "aapt.exe has stooped working" "A problem caused the program to stop working correctly...." I turned on "Preferences | Android | Build | Build Output | Verbose" but I don't see any messages in the console, Log Cat or Errors window. This error happens every time a Clean All finishes, and sporadically whenever Eclipse is running (even if it's in the background, sitting idle, with no open code windows.
I found a few entries like this in the Windows Event Viewer. Only the Process ID and Start Time seem to change. The "exception code 0xc0000005" usually indicates an out of bounds memory access (I think.)
Faulting application aapt.exe, version 0.0.0.0, time stamp 0x52684cb5, faulting module aapt.exe, version 0.0.0.0, time stamp 0x52684cb5, exception code 0xc0000005, fault offset 0x0003cf2a, process id 0x428, application start time 0x01cefa0f2db629c3.
I think it started when I forgot to put an opening quote on an .xml string, but I fixed that and it kept happening. I then deleted the entire project the error occurred in and I still get the message.
Comments / ideas welcome - Joe
I am tracking a bug in my project. From time to time, my app gets killed and in the logcat there is always the following line:
D/Zygote ( xx): Process xxxx terminated by signal (11)
I have been searching about this error and I always find mentions to NDK.
I am developing a project that uses a third-party C library. I do not know the library in great detail, but I can tell you that it does some network communication with a server. In my project there are several Services, some of which use this library.
So my question is, does this error always imply that the problem comes from the C library?
If not, could you give me examples of Java code in Android, that could cause this error as well?
Thanks.
EDIT: By the way, in the logcat output there is no stack trace before the previous line.
Most likely, SIGSEGV was reported before in your log. It may be quite a while earlier than the final message. This is an actual snapshot of one of such crashes in my logs:
01-29 16:00:39.124 F/libc ( 3033): Fatal signal 11 (SIGSEGV) at 0x0000002c (code=1)
... many more ...
01-29 16:00:48.367 D/Zygote ( 116): Process 3033 terminated by signal (11)
You can see that it took almost 10 sec for Zygote to report process termination after the fatal signal was received. Your milage may vary.
The actual reasons for SIGSEGV may be within the third-party C library, or in your Java, or in the way you call the C library. Note, for example, that it's forbidden to make most of JNI calls while a Java Exception is raised.