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
Related
I have a Xamarin.Forms app built for iOS and Android. The application works fine when tested from Visual Studio (in Debug or Release modes and on the emulator or a device). However, when I try to deploy it through AppCenter, the app works on iOS and on Android, it displays the SplashScreen and then a blank white page. None of my controls show up at all...on iOS it is working fine, so the Views seem to be correct..
I hooked up the Android Device Monitor, but I do not seem to get any error messages. I have tried several changes of the project properties (turning ProGuard and MultiDex on and off; changing the Linker settings), but nothing seems to change the behavior.
I am out of ideas to even look for the problem...does anyone have any suggestions? Has anyone seen this before? Is there anywhere that lists the differences in build between Visual Studio and AppCenter?
UPDATE: I have gotten some additional logging from the Device Monitor. There are additional log entries in the version that works, so it seems that something is not running in the deployed version (maybe associated with Google Maps?).
The version not working has these two lines:
01-09 07:23:04.378: I/Google Maps Android API(11219): Google Play services client version: 11400000
01-09 07:23:04.709: I/LaunchCheckinHandler(1410): Displayed {my application name}/md582f1e314fc580d8ae4e7bb0d59c62d55.MainActivity,wp,ca,537
The version that works has these extra log entries:
01-09 07:28:29.970: I/Google Maps Android API(12443): Google Play services client version: 11400000
01-09 07:28:31.807: I/SFPerfTracer(735): triggers: (rate: 0:0) (9563 sw vsyncs) (0 skipped) (121:40138 vsyncs) (123:54057)
01-09 07:28:32.279: I/SFPerfTracer(735): triggers: (rate: 6:1097) (compose: 0:0) (post: 0:3) (render: 0:4) (125:27407 frames) (126:32007)
01-09 07:28:32.279: D/SFPerfTracer(735): layers: (2:8) (StatusBar#0 (0xaf154000): 4:4927)* (com.android.systemui.ImageWallpaper#0 (0xaf113000): 0:228)* (DimLayerController/Stack=0#0 (0xaf10c000): 0:373)* (animation background stackId=1#0 (0xaf192000): 0:20)* (NavigationBar#0 (0xaf445000): 0:493) (com.android.launcher3/com.android.launcher3.CustomizationPanelLauncher#0 (0xaf424000): 0:14)* (com.android.launcher3/com.android.launcher3.CustomizationPanelLauncher#1 (0xaf2fa000): 0:154)* ({my application name}/md582f1e314fc580d8ae4e7bb0d59c62d55.SplashActivity#0 (0xaf437000): 0:3)
01-09 07:28:32.514: W/zygote(12443): JNI RegisterNativeMethods: attempt to register 0 native methods for md58432a647068b097f9637064b8985a5e0.ViewRenderer_2
01-09 07:28:32.652: W/zygote(12443): JNI RegisterNativeMethods: attempt to register 0 native methods for md51558244f76c53b6aeda52c8a337f2c37.ActivityIndicatorRenderer
01-09 07:28:32.764: I/ThermalEngine(967): Thermal-Server: Thermal received msg from override
01-09 07:28:32.764: I/Thermal-Lib(721): Thermal-Lib-Client: Client request sent
01-09 07:28:32.947: W/zygote(12443): JNI RegisterNativeMethods: attempt to register 0 native methods for md51558244f76c53b6aeda52c8a337f2c37.TableViewRenderer
01-09 07:28:33.055: W/zygote(12443): JNI RegisterNativeMethods: attempt to register 0 native methods for md51558244f76c53b6aeda52c8a337f2c37.BaseCellView
01-09 07:28:33.055: W/zygote(12443): JNI RegisterNativeMethods: attempt to register 0 native methods for md51558244f76c53b6aeda52c8a337f2c37.TextCellRenderer_TextCellView
01-09 07:28:33.083: W/zygote(12443): JNI RegisterNativeMethods: attempt to register 0 native methods for md51558244f76c53b6aeda52c8a337f2c37.CellRenderer_RendererHolder
01-09 07:28:33.172: W/View(12443): requestLayout() improperly called by md51558244f76c53b6aeda52c8a337f2c37.ScrollViewContainer{3f9ae0f V.E...... ......ID 0,0-1080,1444} during layout: running second layout pass**
01-09 07:28:33.325: I/LaunchCheckinHandler(1410): Displayed {my application name}/md582f1e314fc580d8ae4e7bb0d59c62d55.MainActivity,wp,ca,3558
Can anyone translate these log messages into English so I have some idea where to look for the issue? IS there something extra that needs to be done with Google Maps when it is deployed versus debug/testing?
Thanks in advance.
It may not relate to the OP's issue but I had the same symptom today:
App working fine on Android when deployed from VS.
Blank screen when deployed from the MDM provider (in my case this was Airwatch Workspace ONE).
No useful information provided in the logs and no errors occurred.
I fixed it by unchecking Android Options -> Use shared runtime
I've noticed an increase in the number of StackOverflow crashes in my app which all seem to point back to Google Play Services Maps. I am currently using version 15.0.1 (com.google.android.gms:play-services-maps:15.0.1) - but this started about two weeks ago when I was still using 15.0.0. There are several crashes, but they all result in StackOverflows when dealing with Hashmaps or Arrays from the Maps code (which is obfuscated). Some examples of the crashes (I just copied the stack traces to the point where it goes to the obfuscated maps code):
Fatal Exception: java.lang.StackOverflowError: stack size 1038KB
at java.util.HashMap.remove(HashMap.java:617)
at com.google.maps.api.android.lib6.gmm6.util.e.d(:com.google.android.gms.dynamite_dynamitemodulesb#12685021#12.6.85 (040306-197041431):29)
Fatal Exception: java.lang.StackOverflowError
at java.util.ArrayList$ArrayListIterator.(ArrayList.java:551)
at java.util.ArrayList.iterator(ArrayList.java:548)
at java.util.Collections$UnmodifiableCollection$1.(Collections.java:953)
at java.util.Collections$UnmodifiableCollection.iterator(Collections.java:952)
at com.google.maps.api.android.lib6.common.i.iterator(:com.google.android.gms.dynamite_dynamitemodulesb#12685002#12.6.85 (000304-197041431):25)
Fatal Exception: java.lang.StackOverflowError: stack size 8MB
at java.util.HashMap.createEntry(HashMap.java:826)
at java.util.HashMap.addEntry(HashMap.java:813)
at java.util.HashMap.put(HashMap.java:436)
at com.google.maps.api.android.lib6.gmm6.util.e.b(:com.google.android.gms.dynamite_dynamitemodulesb#12685020#12.6.85 (040304-197041431):17)
Fatal Exception: java.lang.StackOverflowError: stack size 8MB
at java.util.HashMap.removeEntryForKey(HashMap.java:597)
at java.util.HashMap.remove(HashMap.java:584)
at com.google.maps.api.android.lib6.gmm6.util.e.d(:com.google.android.gms.dynamite_dynamitemodulesb#12685023#12.6.85 (040400-197041431):29)
Fatal Exception: java.lang.StackOverflowError: stack size 8MB
at java.util.ArrayList.(ArrayList.java:170)
at com.google.maps.api.android.lib6.common.i.(:com.google.android.gms.dynamite_dynamitemodulesb#12685020#12.6.85 (040304-197041431):9)
I also have a number of other crashes directly inside the obfuscated maps code.
Some other information: the maps are not inside the main flow of my app, so it is only used by about 8% of my users - around 200 or so calls a day. Today is by far the worst with 62 crashes affecting 13 users - two days ago it was 42 crashes and most other days I have zero crashes.
Operating system versions affected: 7.0, 6.0.1, 4.4.2, 7.1.1, 4.1.2, 5.1, 4.3
Devices: Samsung, Sony, Lenovo, Moto E3 (whatever that is) and a Huawei.
Any help or pointers would be useful!
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
After reading this interesting article about code obfuscation in Android, I'm trying to do it for research purposes but after applying the technique into a classes.dex file I'm getting a crash.
The next is the code I'm trying to run after applying the technique:
0006e8: |[0006e8] com.example.root.bji.MainActivity.paintGUI:()V
0006f8: 1202 |0000: const/4 v2, #int 0 // #0
0006fa: 1a01 0000 |0001: const-string v1, "" // string#0000
0006fe: 1200 |0003: const/4 v0, #int 0 // #0
000700: 1303 1400 |0004: const/16 v3, #int 20 // #14
000704: 3244 0900 |0006: if-eq v4, v4, 000f // +0009
000708: 2600 0300 0000 |0008: fill-array-data v0, 0000000b // +00000003
00070e: 0003 0100 1600 0000 1212 0000 0000 ... |000b: array-data (15 units)
00072c: 0000 |001a: nop // spacer
00072e: 0000 |001b: nop // spacer
... more NOPs ...
000742: 0000 |0025: nop // spacer
000744: 0000 |0026: nop // spacer
000746: 1503 087f |0027: const/high16 v3, #int 2131230720 // #7f08
...
To give you some context, I want to keep clear some assignations like the 0 value into the v2 register at 0x6f8 ("const/4 v2, 0" => 12 02), which will be shown in the GUI at the end of this method (at 0x746 and beyond); and using this obfuscation technique, "hide" the modification of the v2 register setting a value of 1 into the v2 register at 0x716 ("const/4 v2, 1" => 12 12).
If you follow the code at 0x704 the branch is done to 0x716, where the "const/4 v2, 1"r esides, inside the fill-data-array-payload.
And the problem I'm facing is a crash when I'm running the code (I've tried it from 4.3 to 5.1), and what logcat tells me when the crash happens is:
W/dalvikvm(13874): VFY: invalid branch target 9 (-> 0xf) at 0x6
W/dalvikvm(13874): VFY: rejected Lcom/example/root/bji/MainActivity;.paintGUI ()V
W/dalvikvm(13874): VFY: rejecting opcode 0x32 at 0x0006
W/dalvikvm(13874): VFY: rejected Lcom/example/root/bji/MainActivity;.paintGUI ()V
W/dalvikvm(13874): Verifier rejected class Lcom/example/root/bji/MainActivity;
W/dalvikvm(13874): Class init failed in newInstance call (Lcom/example/root/bji/MainActivity;)
D/AndroidRuntime(13874): Shutting down VM
For what I understand in the logs, the OS is rejecting the "if-eq" jump because the offset pointed (I've tried other branch instructions but the result is the same). The only way the code works is if I point to an offset outside the fill-array-data-payload, but then there is no obfuscation technique applied :P.
Anyone have tried something similar to this technique or have fight against this branch verification rejection?
This is not expected to work. The bytecode verifier explicitly checks all branches for validity. The question of whether or not an address is an instruction or data is determined by a linear walk through the method. Data chunks are essentially very large instructions, so they get stepped over.
You can make this work if you modify the .odex output, and set the "pre-verified" flag on the class so the verifier doesn't examine it again -- but you can't distribute an APK that way.
This "obfuscation" technique worked due to an issue in dalvik. This issue was fixed somewhere around the 4.3 timeframe, although I'm not sure the first released version that contained the fix. And lollipop uses ART, which never had this issue.
Here is the change that fixed this issue: https://android-review.googlesource.com/#/c/57985/
I got following in logcat:
03-06 22:53:33.859: D/dalvikvm(13350): Rejecting registerization due to ushr-int/lit8 v4, v7, (#19)
But it didn't stop the flow of the application.
I just want to know why this is appearing, searched a lot about this but found nothing other than description of this opcode ushr-int/lit8 v4, v7 , which is:
Unsigned right shift of v0 (>>>) by the bit positions specified by the literal constant and put the result into vx.
But it doesn't explain about the Rejecting Registerization.
Dalvik opcodes