While testing my app with Android 4.4.2 API level 19 emulator, first call to native code causes a crash. This is the logcat:
01-29 12:12:32.639: E/ALLOC(1232): Requiring 1228800bytes
01-29 12:12:32.639: D/dalvikvm(1232): Trying to load lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0xb4cd9cc8
01-29 12:12:32.639: D/dalvikvm(1232): Added shared lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0xb4cd9cc8
01-29 12:12:32.639: D/dalvikvm(1232): No JNI_OnLoad found in /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0xb4cd9cc8, skipping init
01-29 12:12:32.679: E/dalvikvm(1232): JNI ERROR (app bug): negative buffer capacity: -5457750921690562560
01-29 12:12:32.679: I/dalvikvm(1232): "main" prio=5 tid=1 RUNNABLE
01-29 12:12:32.679: I/dalvikvm(1232): | group="main" sCount=0 dsCount=0 obj=0xb4a2aca8 self=0xb70c4380
01-29 12:12:32.689: I/dalvikvm(1232): | sysTid=1232 nice=0 sched=0/0 cgrp=apps handle=-1225698988
01-29 12:12:32.689: I/dalvikvm(1232): | state=R schedstat=( 1140000000 1520000000 1339 ) utm=83 stm=31 core=0
01-29 12:12:32.729: I/dalvikvm(1232): at it.jcsoftmobile.snailcamera.ImageLab.NativeAlloc(Native Method)
This is the logcat of the same piece of code, same app, same screen-size emulator, ... the only thing that differs is Android version (4.3):
01-28 19:52:51.543: E/ALLOC(12661): Requiring 1228800bytes
01-28 19:52:51.563: D/dalvikvm(12661): Trying to load lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0x416e2fd0
01-28 19:52:51.613: D/dalvikvm(12661): Added shared lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0x416e2fd0
01-28 19:52:51.613: D/dalvikvm(12661): No JNI_OnLoad found in /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0x416e2fd0, skipping init
01-28 19:52:51.922: D/dalvikvm(12661): GC_FOR_ALLOC freed 68K, 4% free 3447K/3584K, paused 302ms, total 303ms
01-28 19:52:51.922: I/dalvikvm-heap(12661): Grow heap (frag case) to 3.865MB for 460816-byte allocation
I read something about ART vm, but i think this is not the case, because logcat explicitly tags both outputs as "dalvikvm".
My app was running ok on every tested devices and emulators, starting from GB 2.3.3 to JB 4.3, KitKat is the first version that gave me problems.
Maybe KitKat has a different loadLibrary management? Should i implement (i dunno how!) JNI_OnLoad?
Any idea?
EDIT
I tested my app on a Nexus 7 with KK 4.4.2, and it's working fine.
Here's the C code that generates the exception:
jobject Java_my_package_NativeAlloc(JNIEnv* env, jlong numBytes) {
void *ptr = (char*)malloc(numBytes);
return (*env)->NewDirectByteBuffer(env, ptr, numBytes);
}
and here's the Java code that calls it:
public native static ByteBuffer NativeAlloc(int size);
There is of course an issue, as Java int size (32-bit) becomes a JNI jlong numBytes (64-bit), my fault.
But why this code worked fine until 4.4.2 emulator?
Your function prototype is incorrect, causing your arguments to be intermixed in a platform-dependent way and the requested size to be potentially corrupted.
public native static ByteBuffer NativeAlloc(int size);
Should correspond to
jobject Java_my_package_NativeAlloc(JNIEnv* env, jclass someClass, jint numBytes)
By omitting the jclass argument you risk corrupting the other arguments.
This may have balanced out the jint/jlong mistake in your code on some platforms, but not on others.
Not really an answer, but... Your app is Requiring 1228800bytes and -5457750921690562560 is a 64-bit number, whose lower part is 1228800 (0x12C000) and the higher part is 0xB4422C74. Probably a 64-bit fetch is done from an address containing a 32-bit number (the length). If you could place 0 after the length, this would probably solve the problem. But you have to locate the place.
Does the bug happen on a 64-bit desktop system? If so, you could try a 32-bit version.
Related
I am getting this error -
A/libc: Fatal signal 31 (SIGSYS), code 1 in tid 4168 (m.messagingdapp)
When I upgrade my app from API 24 to 26 (have to do to get java.nio.file features). It is the only error that I can see in my logcat. It works fine when running with API 24. It gets the error when accessing an API I'm using called go-ethereum on this line -
String f = this.getFilesDir() + "/.ethereum";
Long n = Geth.LightScryptN;
Long p = Geth.LightScryptP;
AccountManager am = Geth.newAccountManager(f, n, p); //HERE
There seem to be lots of other errors on different parts of the logcat in the drop down menu i.e system_process. However, I am new to android and don't really know what I am looking for (I have googled all of them separately but have gotten no fix). Thanks.
Full lolcat -
07-25 22:17:14.774 9625-9625/? I/zygote: Not late-enabling -Xcheck:jni
(already on)
07-25 22:17:14.825 9625-9625/? W/zygote: Unexpected CPU variant for X86
using defaults: x86
07-25 22:17:15.181 9625-9625/benkrarup.ethereum.messagingdapp W/zygote:
Class android.support.v4.util.SimpleArrayMap failed lock verification
and will run slower.
07-25 22:17:15.181 9625-9625/benkrarup.ethereum.messagingdapp W/zygote:
Common causes for lock verification issues are non-optimized dex code
07-25 22:17:15.181 9625-9625/benkrarup.ethereum.messagingdapp W/zygote:
and incorrect proguard optimizations.
07-25 22:17:15.184 9625-9625/benkrarup.ethereum.messagingdapp W/zygote:
Class cz.msebera.android.httpclient.conn.util.PublicSuffixMatcherLoader
failed lock verification and will run slower.
07-25 22:17:15.191 9625-9625/benkrarup.ethereum.messagingdapp
D/NetworkSecurityConfig: No Network Security Config specified, using
platform default
07-25 22:17:15.216 9625-9625/benkrarup.ethereum.messagingdapp
W/Java7Support: Unable to load JDK7 types (annotations,
java.nio.file.Path): no Java7 support added
07-25 22:17:15.596 9625-9657/benkrarup.ethereum.messagingdapp A/libc:
Fatal signal 31 (SIGSYS), code 1 in tid 9657 (m.messagingdapp)
Android 8 O (SDK 26) limits which system calls are allowed for security reasons by enabling a feature called secure computing in the Linux kernel.
This means only whitelisted calls can be executed and that any other call will result in signal 31 (SIGSYS), code 1 (SYS_SECCOMP), like you are experiencing. You will need to examine the stack trace of this signal to find out which system call was not allowed (which was not listed completely in your question).
You can find a list of allowed calls here. Any other call is not allowed.
You can find what Google wrote about this here.
Some time ago I developed a jni wrapper for the C libspeex audio codec.
Recently I had some problem in compiling and running this with the ndk r10e, since the audio encode function crashed in runtime.
Finally I found that when I compile with
NDK_TOOLCHAIN_VERSION:=4.8
the native code runs while with
NDK_TOOLCHAIN_VERSION:=clang
it crashes. I wonder about the difference between the two toolchains.
The logcat of the crash:
11-02 14:26:33.642 1908-1908/com.ermes.intau D/dalvikvm: GC_FOR_ALLOC freed 1248K, 20% free 34140K/42456K, paused 102ms, total 102ms
11-02 14:26:33.642 1908-2514/com.ermes.intau A/libc: Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 2514 (Thread-103909)
11-02 14:26:33.742 1908-1908/com.ermes.intau D/dalvikvm: GC_FOR_ALLOC freed 6K, 18% free 34883K/42456K, paused 89ms, total 89ms
gcc and clang are completely different C compilers. They have no common code.
Of course they aren't developed in a vacuum. The developers of both compilers do compete with each other to generate the best / fastest machine code. While the optimisations they both perform may be based on the same ideas, they both have different edge cases that will be compiled differently.
With clang being the newest compiler to be developed, they do try to compile other open source projects that have a history of being compiled by gcc. With either clang or the open source project being changed whenever bugs are found.
The C language standard also leaves a lot of behaviour undefined. Things like dividing by zero, dereferencing a NULL pointer, signed integer overflows, alignment of stack allocations... Both compilers will exploit these edge cases to generate faster code. If a block of code "might" do something weird, the compiler can assume that the developer knows what they are doing and have handled these cases elsewhere.
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
I'm using Android Studio 1.0.2 in ubuntu 14.04 on an app project migrated from Eclipse. I'm new to both Studio/IntelliJ and Gradle. When I go to debug the app by clicking on the debug icon in Studio:
the app is built by Gradle
the Choose Device dialog pops up and I can select my phone
the Debug pane says under Variables: "Connected to the target VM, address: 'localhost:8601',transport: 'socket'
but none of the debugger icons for stepping into or over the code, etc, are enabled and the debugger won't stop at any breakpoints.
I haven't set android:debuggable="true" in my manifest as that seems to be deprecated now.
I've tried removing all but one JDK as suggested here but I still have this problem.
The weird thing is that sometimes the debugger does behave as expected but, 8 or 9 times out of 10, it just won't work. This is immensely frustrating! I get the same behaviour with the same code and version of Studio on another machine as well. Any ideas on how to get Studio's debugger to behave reliably please?
Update 23 Jan: The same instance of Studio is able to debug a newly created 'Hello World' app fine, so it's probably something to do with my app's project which is the problem, but I don't know what. Maybe it only occurs for some projects migrated from Eclipse - e.g., when manifests are merged; but this is a complete guess.
Update 7 Feb: If I set the debugger to suspend on any exception then I see this exception thrown first: libcore.io.ErrnoException: access failed: ENOENT (No such file or directory). The stacktrace for the main thread is:
<1> main#830017070344, prio=5, in group 'main', status: 'RUNNING'
at libcore.io.ForwardingOs.access(ForwardingOs.java:38)
at java.io.File.doAccess(File.java:283)
at java.io.File.exists(File.java:363)
at dalvik.system.DexPathList.splitAndAdd(DexPathList.java:168)
at dalvik.system.DexPathList.splitPaths(DexPathList.java:149)
at dalvik.system.DexPathList.splitLibraryPath(DexPathList.java:130)
at dalvik.system.DexPathList.<init>(DexPathList.java:98)
at dalvik.system.BaseDexClassLoader.<init>(BaseDexClassLoader.java:52)
at dalvik.system.PathClassLoader.<init>(PathClassLoader.java:65)
at android.app.ApplicationLoaders.getClassLoader(ApplicationLoaders.java:57)
at android.app.LoadedApk.getClassLoader(LoadedApk.java:317)
at android.app.LoadedApk.makeApplication(LoadedApk.java:493)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4170)
at android.app.ActivityThread.access$1400(ActivityThread.java:134)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1278)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4867)
at java.lang.reflect.Method.invokeNative(Method.java:-1)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1007)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:774)
at dalvik.system.NativeStart.main(NativeStart.java:-1)
This is followed by loads of BootClassLoader exceptions as the classloader tries and fails to load the classes in my app, and Google's classes. On my device all I see is the action bar - nothing else:(. I saw someone else have a similar problem here. Interestingly they also migrated from Eclipse to IntelliJ but, unlike them, I didn't have the problem in Eclipse already AFAIK. They never seemed to get to the bottom of it. Any ideas please? I still don't understand what triggers this because sometimes the debugger does work as expected.
Short answer: there's a known bug in Google Play Services v6.5.87 which means that Google Analytics (GA) is highly likely to deadlock when GoogleAnalytics.getInstance() tries to load the XML tracker file defined in your manifest. You can work around it by configuring your GA tracker programatically, as I did, or by downgrading the version of Google Play Services you're using (or waiting for a fix in a later release!). See here, here and here for more info.
My 'Hello World' app worked because it didn't use GA. I noticed that the dependencies section of my app's build.gradle file in Android Studio had said this:
compile 'com.google.android.gms:play-services:+'
I'm guessing the original Eclipse version of my app was referencing an older version of Google Play Services that did not have this issue and that when the app was migrated to Android Studio it was coincidentally given v6.5.87 with this bug. Thanks a lot Google! I've since changed the above line to
compile 'com.google.android.gms:play-services:6.5.87'
so at least I know exactly what I'm getting and can decide myself when to upgrade!
As for the class-loading errors they appear to be unrelated (and harmless?) but I still don't know what's causing them.
Long answer: I branched my code and stripped the app right down to its bare essentials with only a single activity. It was still crashing on startup but this time I noticed this line in LogCat:
I/dalvikvm﹕ Wrote stack traces to '/data/anr/traces.txt'
I used this command in my filesystem to pull the trace dump from my phone to my computer:
~/android-sdks/platform-tools$ ./adb pull /data/anr/traces.txt
At the head of traces.txt I saw this (my app packages and names have been changed):
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0)
"main" prio=5 tid=1 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x41606508 self=0x415f6660
| sysTid=4925 nice=0 sched=0/0 cgrp=[no-cpu-subsys] handle=1074638640
| schedstat=( 71380610 113708500 297 ) utm=3 stm=4 core=1
at com.google.android.gms.analytics.ae.getLogger((null):~-1)
- waiting to lock <0x420608a0> held by tid=13 (client_id_fetcher)
at com.google.android.gms.analytics.ae.V((null):-1)
at com.google.android.gms.analytics.GoogleAnalytics.a((null):-1)
at com.google.android.gms.analytics.GoogleAnalytics.eZ((null):-1)
at com.google.android.gms.analytics.GoogleAnalytics.<init>((null):-1)
at com.google.android.gms.analytics.GoogleAnalytics.<init>((null):-1)
at com.google.android.gms.analytics.GoogleAnalytics.getInstance((null):-1)
at com.mycompany.mypackage.MyApp.getTracker(MyApp.java:61)
at com.mycompany.mypackage.MyActivity.onCreate(MyActivity.java:125)
at android.app.Activity.performCreate(Activity.java:5047)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1094)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2056)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2117)
at android.app.ActivityThread.access$700(ActivityThread.java:134)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1218)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:4867)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1007)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:774)
at dalvik.system.NativeStart.main(Native Method)
"client_id_fetcher" prio=5 tid=13 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x4205e778 self=0x5a51d948
| sysTid=4941 nice=0 sched=0/0 cgrp=[no-cpu-subsys] handle=1515314584
| schedstat=( 16052255 21850583 224 ) utm=1 stm=0 core=1
at com.google.android.gms.analytics.GoogleAnalytics.eY((null):~-1)
- waiting to lock <0x4205af48> held by tid=1 (main)
at com.google.android.gms.analytics.ae.getLogger((null):-1)
at com.google.android.gms.analytics.ae.V((null):-1)
at com.google.android.gms.analytics.k.eq((null):-1)
at com.google.android.gms.analytics.k$1.run((null):-1)
"GAThread" prio=5 tid=12 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x4205b950 self=0x415e59c8
| sysTid=4940 nice=10 sched=0/0 cgrp=[no-cpu-subsys] handle=1096703512
| schedstat=( 15808103 21026609 173 ) utm=1 stm=0 core=1
at com.google.android.gms.analytics.GoogleAnalytics.getInstance((null):~-1)
- waiting to lock <0x4205af48> held by tid=1 (main)
at com.google.android.gms.analytics.w.<init>((null):-1)
at com.google.android.gms.analytics.x.init((null):-1)
at com.google.android.gms.analytics.x.run((null):-1)
You can see thread id (tid) 1, "main", is calling GoogleAnalytics.getInstance() but is blocked waiting for lock <0x420608a0> held by tid=13 (client_id_fetcher)
But thread 13, "client_id_fetcher", is blocked waiting for lock <0x4205af48> held by tid=1 (main). Deadlock! (Thread 12, "GAThread" is also blocked waiting for the same lock.) After seeing this I was able to Google for deadlock in GoogleAnalytics.getInstance() and that led me to the workarounds mentioned above. Hope this helps someone else because it took me a long time to track this one down!
We have an Android app that has been out for several years. We recently got this message from a user.
"I have had excellent use of your app on my Tab 2 10.1 but when I moved to a Samsung Tab 3 10.1 I get a screen lock after a few seconds operation and then the app closes, thereby making it impossible to use."
I asked the user to send me a log file of the crash. I didn't see any obvious crash indication, but I did see the following unusual Dalvik entries:
D/dalvikvm(10652): Rejecting registerization due to +iget-object-quick v1, v3, (#12)
D/dalvikvm(10652): Rejecting registerization due to +iget-object-quick v5, v7, (#8)
D/dalvikvm(10652): Rejecting registerization due to +iget-object-quick v1, v3, (#12)
D/dalvikvm(10652): Rejecting registerization due to +iget-object-quick v5, v7, (#8)
D/dalvikvm(10652): Rejecting registerization due to +iget-object-quick v2, v3, (#8)
D/dalvikvm(10652): Rejecting registerization due to +iget-object-quick v2, v3, (#8)
E/FlurryDataSender(10652): --onReport 0aaed6a1-d074-4f9c-8e96-d015a4c071e7 sent. HTTP response: 200 : OK
D/dalvikvm(10652): GC_EXPLICIT freed 679K, 23% free 7357K/9532K, paused 1ms+2ms, total 21ms
E/dalvikvm(10652): JIT_INFO: We cannot transfer from GP reg to XMM and vice versa
I/dalvikvm(10652): JIT_INFO: Unsupported bytecode if-lt
I/dalvikvm(10652): Could not compile trace for Lcom/southernstars/skysafari/Utility;createTextAtlasInfo, offset 443
I/dalvikvm(10652): ++++++++++++++++++++++++++++++++++++++++++++
I/dalvikvm(10652): JIT_INFO: Issues in trace Lcom/southernstars/skysafari/Utility;createTextAtlasInfo, offset 443
E/dalvikvm(10652): The following issues were seen:
I/dalvikvm(10652): Issue: Trace contains bytecode with no implementation
I/dalvikvm(10652): Issue: Issue registerizing the trace in the backend
E/dalvikvm(10652): Trying to turn backend registerization off
E/dalvikvm(10652): ++++++++++++++++++++++++++++++++++++++++++++
E/dalvikvm(10652): JIT_INFO: We cannot transfer from GP reg to XMM and vice versa
I/dalvikvm(10652): JIT_INFO: Unsupported bytecode if-lt
I/dalvikvm(10652): Could not compile trace for Lcom/southernstars/skysafari/Utility;createTextAtlasInfo, offset 409
I/dalvikvm(10652): ++++++++++++++++++++++++++++++++++++++++++++
I/dalvikvm(10652): JIT_INFO: Issues in trace Lcom/southernstars/skysafari/Utility;createTextAtlasInfo, offset 409
E/dalvikvm(10652): The following issues were seen:
I/dalvikvm(10652): Issue: Trace contains bytecode with no implementation
I/dalvikvm(10652): Issue: Issue registerizing the trace in the backend
E/dalvikvm(10652): Trying to turn backend registerization off
E/dalvikvm(10652): ++++++++++++++++++++++++++++++++++++++++++++
Anyone have any thoughts about what this means? We have many thousands of users and this is the first report of something like this. Is there something fundamentally different about the Galaxy Tab 3?
The Galaxy Tab 3 10.1 is one of newer Android Tablets powered by an Intel Atom Z2560.
Whilst most Android apps should work on Intel without a problem you should try this in your dev environment first.
I did finally figure this out. The crash was down in the C library (we have native code in the app). I still am not sure why it crashed but we changed a sscanf() call and it fixed it. The old code was doing a %100c to copy a string and we changed it to %100s. Something about the data being copied beyond the \0 with the %100c was causing the problem (no, all the memory was allocated).
This exact code has been used on many related projects and on many platforms for over a decade without at problem. I can only guess that Samsung was using a slightly different C-library that was not fully compatible.
Bill
I would like to know how I can troubleshoot high memory usage problems of my app on Android. I've search the internet and found out that the DDMS plugin is useful in taking a memory dump of the heap for my app. This however has been useless.
The app "Usage Timelines Free" is showing 94 MBs of memory used, while the DDMS heap dump shows me a total of 8.4 MBs, with the suspected leaks being the resource files.
When I generate a dump from adb (dumpsys meminfo), I get:
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 20 8 20 54588 39431 1892
Dalvik 6732 9952 6396 10756 10028 728
Cursor 0 0 0
Ashmem 184 0 184
Other dev 11462 1172 11384
.so mmap 2467 2072 1156
.jar mmap 0 0 0
.apk mmap 48 0 0
.ttf mmap 2 0 0
.dex mmap 1037 0 0
Other mmap 41 16 32
Unknown 46352 292 46348
TOTAL 68345 13512 65520 65344 49459 2620
How can I know what is behind this huge memory consumption. My app is a foreground monitor service which runs forever, with a few activities which are accessed a few times per day.
Thanks.
Minimize your android data usage. Check the link :http://engineroots.games4punk.com/minimize-your-android-data-usage/
DDMS and got a heap memory dump. It only showed 8.4 MBs being used!
Then you are only using 8.4MB of heap space after a complete garbage collection (a net effect of creating the heap dump).
Note that if you ran this on Android 1.x/2.x, MAT will not report space consumed by bitmaps. Always try to dump the heap from an Android 3.0+ device or emulator.
When I generate a dump from adb (dumpsys meminfo), I get:
My guess is that you are running this on an Android 1.x/2.x device or emulator, and you have a lot of bitmap memory. Try running your heap dump and other tests on an Android 3.0+ environment.
Also, bear in mind that adb dumpsys meminfo does not perform a complete garbage collection, whereas dumping the HPROF file does. The Android garbage collector is optimized to minimize CPU utilization and therefore does not attempt to perform a complete garbage collection. Hence, at runtime, the heap is usually filled with garbage that will be reclaimed, as needed, by the GC engine.
You might also wish to read Dianne Hackborn's essay on this subject.