I have created simplified test code now which crashes the LG G3 with the error I have provided on both Xwalk 9.38.208.1 and 10.39.227.0. Other devices I have access to do not seem to crash with this test code.
Find the code here in the master branch: https://bitbucket.org/whyameye/crosswalk-tests/src The code is as basic I knew how to make it to cause the crash. In essence it: - create 2 divs, each the size of the screen - creates 60 canvases in each div. Each canvas is 170x200 pixels - loads a 170x200 pixel image into each canvas - performs a left, then right screen translation to move the divs with canvases on them on/off screen. Sometimes the app crashes immediately and sometimes it does the translations up to a few minutes before crashing. If the LG G3 is an anomaly and all other devices run my code fine I can live with that. My concern is that there are thousands of different Android devices out there and I cannot test on them all. The fact that I found one device that crashes my code out of only about 1/2 dozen I have tested concerns me. It seems to me from what I know right now there could be a large percentage of devices on which my code crashes. For convenience here's the error again from logcat: W/Binder ( 1352): Caught a RuntimeException from the binder stub implementation. W/Binder ( 1352): java.lang.NullPointerException W/Binder ( 1352): at android.inputmethodservice.IInputMethodWrapper.setSessionEnabled(IInputMethodWrapper.java:280) W/Binder ( 1352): at com.android.internal.view.IInputMethod$Stub.onTransact(IInputMethod.java:129) W/Binder ( 1352): at android.os.Binder.execTransact(Binder.java:407) W/Binder ( 1352): at dalvik.system.NativeStart.run(Native Method) -John -------------------------------------------- On Thu, 10/23/14, Min, Hongbo <[email protected]> wrote: Subject: RE: [Crosswalk-help] stability of Crosswalk across multiple devices for canvas-heavy app To: "John Harrison" <[email protected]> Cc: "[email protected]" <[email protected]> Date: Thursday, October 23, 2014, 12:50 AM Till now, according to the information you provided, it seems it is a device specific issue happened on LG G3 device. Unfortunately, I don't have such a device. I am also on the IRC, my name is 'hmin'. Ping me if you are free. Regards Hongbo ________________________________________ From: John Harrison [[email protected]] Sent: Thursday, October 23, 2014 1:20 PM To: Min, Hongbo Cc: [email protected] Subject: RE: [Crosswalk-help] stability of Crosswalk across multiple devices for canvas-heavy app Sorry, I forgot to cc the list. If it is an easier/quicker way to communicate, I am often in the #crosswalk channel in Freenode on IRC. My handle is "whyameye." Also you asked on the crashlog for Crosswalk 8 and 9. I need to check on 8. For 9 it is the same as 10: W/Binder ( 1335): Caught a RuntimeException from the binder stub implementation... -John -------------------------------------------- On Wed, 10/22/14, John Harrison <[email protected]> wrote: Subject: RE: [Crosswalk-help] stability of Crosswalk across multiple devices for canvas-heavy app To: "HongboMin" <[email protected]> Date: Wednesday, October 22, 2014, 11:55 PM I have tried running in Chrome on Android v 38.0.2125.102 and it seems to work fine. I have tried Crosswalk 8.37.189.14 and 9.38.208.7 and it crashes on these versions. I also told you earlier that if I used the xwalk flag --disable-accelerated-2d-canvas with Crosswalk it wouldn't crash, but I was wrong on that. It still crashes with that flag, just not as often. Sometimes the app doesn't completely crash but it seems like the DOM is somehow corrupted. Images will be completely missing that should be there. I'm wondering if it could be some sort of threading issue. However I tried every flag I could imagine that was related to threading and nothing helped. -John -------------------------------------------- On Wed, 10/22/14, Min, Hongbo <[email protected]> wrote: Subject: RE: [Crosswalk-help] stability of Crosswalk across multiple devices for canvas-heavy app To: "John Harrison" <[email protected]> Cc: "[email protected]" <[email protected]> Date: Wednesday, October 22, 2014, 10:05 PM John, There is still some differences between Chromium WebView and Crosswalk in graphics rendering even though both of them are based on Chromium. For Chromium 30 WebView, it doesn't support accelerated canvas rendering while Crosswalk supports. The exception captured from adb logcat may be not related to canvas 2d, I am not sure if it is another bug introduced by rebasing. To filter these noises, could you please have a try the following 3 options? 1. Try to open your app in Chrome on Android if possible, and let me know the Chrome version. 2. Try to use Crosswalk beta and stable version and verify if the crash issue still exists. Stable: https://download.01.org/crosswalk/releases/crosswalk/android/stable/8.37.189.14/, and Beta: https://download.01.org/crosswalk/releases/crosswalk/android/beta/9.38.208.7/, and let me know the crash log. Again, it is very likely that your app expose a bug in accelerated canvas 2d. Regards Hongbo ________________________________ From: John Harrison [[email protected]] on behalf of John Harrison [[email protected]] Sent: Thursday, October 23, 2014 5:42 AM To: Min, Hongbo Cc: [email protected] Subject: Re: [Crosswalk-help] stability of Crosswalk across multiple devices for canvas-heavy app Also I forgot to mention in earlier emails that my code runs without crashes on the LG G3 on Chromium 30 using Cordova webview without Crosswalk: Mozilla/5.0 (Linux; Android 4.4.2; LGLS990 Build/KVT49L.LS990ZV4) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36" -John On 10/22/2014 11:18 AM, John Harrison wrote: Hongbo et al: I'm up for sharing the code off-list if it comes to that. Between the politics of sharing the code and the complexity of the code itself, I had thought it would be easier for all of us if I could isolate the problem in my code and just share that. Despite my attempts, though, I haven't successfully been able to isolate the problem. Here is the error I am consistently seeing from logcat when the app crashes. It is different than the error I reported earlier, and I'm not sure why it changed. Perhaps it is because of the switch to canary: W/Binder ( 1335): Caught a RuntimeException from the binder stub implementation. W/Binder ( 1335): java.lang.NullPointerException W/Binder ( 1335): at android.inputmethodservice.IInputMethodWrapper.setSessionEnabled(IInputMethodWrapper.java:280) W/Binder ( 1335): at com.android.internal.view.IInputMethod$Stub.onTransact(IInputMethod.java:129) W/Binder ( 1335): at android.os.Binder.execTransact(Binder.java:407) W/Binder ( 1335): at dalvik.system.NativeStart.run(Native Method) I'm using canary 10.39.2227.0 as you suggested. The LG G3 is the only device I am aware of triggering this error, but I have tested on only 6 or so devices. If you have an LG G3 to test on and you are willing to deal with messy code that performs a lot of operations unrelated to this problem, maybe that is a reasonable way to go, as I am making slow progress on my end. -John On 10/20/2014 12:26 AM, Min, Hongbo wrote: Hi, John Actually, the amount of available GPU memory reported is not exactly accurate on Android device. Unlike Desktop GPU, there is no straightforward way to query available gpu memory. On Android device, its value is heuristically calculated from the available physical RAM (yes, RAM) and Davik VM, and make sure it is in a pre-defined range. As a result, it is possible that you force to set available gpu memory to 100MB but only 8MB is reported. Right now let's focus on the issue you encountered, not the estimated amount of gpu memory. The issue your encountered when using Crosswalk is, the behavior of your app is not consistent cross multiple device, e.g. crash on some device, I suspect a bug in canvas is exposed by your app. Would you like to share your source code to us to diagnose the root cause? If you are hesitant to do that, then capture the output from adb logcat after launching your app, especially for the crash point. It is recommended to use the latest Crosswalk canary version https://download.01.org/crosswalk/releases/crosswalk/android/canary/10.39.227.0/ to try it again. Regards Hongbo ________________________________ From: John Harrison [[email protected]<mailto:[email protected]>] on behalf of John Harrison [[email protected]<mailto:[email protected]>] Sent: Sunday, October 19, 2014 3:51 AM To: Min, Hongbo; [email protected]<mailto:[email protected]> Subject: Re: [Crosswalk-help] stability of Crosswalk across multiple devices for canvas-heavy app Thanks for the detailed response. My responses are interspersed with yours below. To make them easier to spot I color-coded them. On 10/15/2014 12:02 AM, Min, Hongbo wrote: Hi, John Thanks for your elaborate report. It is very informative! See my comment as below. -----Original Message----- From: Crosswalk-help [mailto:[email protected] project.org] On Behalf Of John Harrison Sent: Monday, October 13, 2014 10:15 AM To: [email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]> Subject: [Crosswalk-help] stability of Crosswalk across multiple devices for canvas-heavy app I recently completed a Cordova app which runs stable and fast on iOS7 and iOS8 devices. It runs in Webview for Android devices but is slow, so I migrated it over to Crosswalk. The results were initially promising as Crosswalk 8 ran fast and stable on the tested device. However, I found the results were different on other Android devices. After trying 6 different versions of Crosswalk I finally released the app using Crosswalk 7.36.154.12 as it seemed the most stable on the tested devices. However, the app is still not stable on all Android devices I have tested on. Below are my notes for each version I tried and the results I found on the various devices. [hmin] The work you did is very helpful for us to continuously improve Crosswalk. Thanks a lot again! The app manipulates multiple Canvas elements and relies heavily on GPU hardware acceleration. I'd love to find a way that it might be stable on all Android 4.x devices using Crosswalk. I'd love some advice as to what I might try next or what tests might be helpful to the Crosswalk developers. And...I've tried these Crosswalk versions with every GPU and memory flag under the sun. Unless I shut off hardware acceleration for the canvas element or other hardware acceleration (which results in poor performance) the behavior is the same: 6.35.131.13 - appeared stable with quick test on LG G3 Android 4.4.2 - GPU reports only 8MB available on Motorola Droid Mini Android 4.4.4 according to --show-fps-counter. This causes poor performance as the GPU memory needed is often exceeded. Crosswalk versions 8,9,10 do not have this problem with this device as these versions report over 100MB of GPU memory on this same device. [hmin] In Crosswalk 6, the max available GPU memory is hard-coded to 8MB in GpuMemoryManager, so it doesn't reflect the real number on the device. See the code https://github.com/crosswalk-project/chromium-crosswalk/blob/crosswalk-6/35.0.1916.17/content/common/gpu/gpu_memory_manager.cc#L81. But from Crosswalk 8, 9, 10, the hard-coded number is changed to 256MB, https://github.com/crosswalk-project/chromium-crosswalk/blob/crosswalk-9/38.0.2125.23/content/common/gpu/gpu_memory_manager.cc#L104. Same as Chromium, Crosswalk allows you to force to set the available gpu memory by passing '--force-gpu-mem-available-mb' command line option. With this option, you can instruct Crosswalk to set the total amount of memory that can be allocated for GPU resources when rendering the page. You may want to use this option to increase the amount of gpu memory to see if the performance is improved accordingly. Since you are using Cordova-Crosswalk to package an app, the usage of command line option is a bit tricky if make_apk.py script is not used. For your information, you can follow the following instructions to add command line options by manual: 1. Create a new empty file named as xwalk-command-line in <assets> folder; 2. Add "xwalk --force-gpu-mem-available-mb=100' to xwalk-command-line file. Re-package the app using cordova toolchain, and you will get the command line option works. Testing on Xwalk 7, unfortunately this didn't work. I added in my xwalk-command-line: xwalk --force-gpu-mem-available-mb=100 --show-fps-counter I know the command line is being read because the fps counter shows (and does not show if I remove the line). However the amount of memory reported as MAX still is 8MB. - If wifi/mobile network is not available exhibits strange erratic behavior in the app. This is in spite of the fact that the app does not use wifi/mobile network. [hmin] Do you remember the error message? Is it saying something like "application ... server timeout ..."? I don't remember the error message, but this was on Xwalk 6 so it might not be worth our time since it does not seem a problem with later versions. If it is helpful to you I can migrate back to Xwalk 6 and catch the error. 7.36.154.12 and 7.36.154.13: - exact same behavior as 6.35.131.13 except: - no issue with wifi/mobile - runs but is not stable on LG G3 Android 4.4.2. Erratic crashes. Android log for crash unknown. [hmin] If you app is using canvas element, and you also turn on ignore-gpu-blacklist option, it is very possible that the app would crash by accident since it may encounter a bug in gpu driver. I tried that. The behavior is the same. The only thing that makes the app rock-solid with no crashes is the command line --disable-accelerated-2d-canvas but then the performance is laggy. 8.37.189.12, 9.38.208.1, 10.38.219.0 - app immediately crashes on LG G3 Android 4.4.2. Android log reports GPU Parse Error 2. [hmin] Maybe it triggers a bug in gpu driver if ignore-gpu-blacklist. - strange delays of up to several seconds at a time on x86 Asus ME302 running Android 4.3. Also is not fully stable (sometimes crashes at erratic times. Log unknown. Note: app has both x86 and ARM Crosswalk so Crosswalk is native x86 code, not running in ARM emulator.) - GPU reports 100MB available on Motorola Droid Mini, which is stable and runs fast and well. (Why does this same device report only 8MB available on Xwalk versions 6 and 7?) [hmin] The amount reported by show-fps-counter is a number hard-coded by Crosswalk (Chromium), it varies between different versions, see the above explanations. There are 2 categories showed in FPS head-up-display: USED and MAX. The USED means that the total bytes allocated for page rendering, while the MAX means the total bytes of GPU memory budgets. Is the 100MB reported by USED or MAX category? 100MB was in the MAX category. The app is built on Cordova 3.6.3-0.2.13 and uses the following plugins: org.apache.cordova.console 0.2.7 "Console" org.apache.cordova.device 0.2.8 "Device" org.apache.cordova.file 1.0.1 "File" org.apache.cordova.inappbrowser 0.5.2 "InAppBrowser" org.apache.cordova.media 0.2.12 "Media" org.apache.cordova.splashscreen 0.3.3 "Splashscreen" org.apache.cordova.statusbar 0.1.7 "StatusBar" Thanks in advance for any help, -John _______________________________________________ Crosswalk-help mailing list [email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-help _______________________________________________ Crosswalk-help mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-help
