[Android] Production app crashing in runtime

I was asked by the NativeScript-team to post my issue here, so here it goes. Thanks in advance.

On February 26th we published a new version of both our Android and iOS apps to the app stores. The published apps are based on {N} v2.4. The issues we are having are only on Android.

We use Google-Analytics innside the app, so we try to log exceptions this way. But this only logs the first line of the exception, for some reason.

Still, we see an outrageous increase in the amount of crashes logged. Since the release date and to this date, there are in total 2240 logged exceptions/crashes.

This is just a part of them. There are more, and those are all OutOfMemoryError exceptions (around 400 of them): http://i.imgur.com/lf7Z95h.png

The problem we are having is that (of course) we are struggling to reproduce many of these. The one we are able to reproduce is the OutOfMemoryError. It happens at random, just tapping around the app, opening/closing different views. Our app is image-rich, but the images are not bigger than 200kb. We also use a image-caching plugin called nativescript-web-image-cache.

One other exception, IllegalStateException (@ViewPager:populate:1167) {main} is probably caused by our own Carousel plugin. But we are still having a hard time to reproduce the issue locally, and are still looking into it. https://github.com/manijak/nativescript-carousel

We are using Genymotion as our main emulator for Android. And for devices we have several phones (Samsung , LG, Nexus) and also a high-end tablet (Nvidia Shield K1). The only exception we have managed to reproduce is still, OutOfMemoryError.

Luckily, we have some users who care, so they reported the crashes, so have have full stack-traces on some of them. I can provide those if needed.

Please, let me know if you need more information regarding the issue(s). I could also provide access to the source code if needed.

Apps are available here:
Android: https://play.google.com/store/apps/details?id=ba.fkzeljeznicar
iOS: https://itunes.apple.com/us/app/fk-%C5%BEeljezni%C4%8Dar/id1097417103?mt=8

@manijak

@manijak can you please provide the stack trace logs. Access to the source code will also be of great help to investigate what is causing the memory leak. You can send me private message in the community slack (niki_iliev) or to my email (nikolay.iliev at progress com)

@NathanaelA

@NathanaelA here's some more info in addition to what you said. It might be helpful to others https://docs.nativescript.org/runtimes/android/advanced-topics/memory-management

Did not know about the memory-management article or the 'android.GC()' function. I will look more into this for sure. Thanks!

@manijak

@manijak

Here is what we have so far:
Regarding the error log from com.tns.NativeScriptException (com.tns.Runtime.callJSMethodNative)_2.txt

java.lang.RuntimeException: Unable to resume activity {ba.fkzeljeznicar/com.tns.NativeScriptActivity}: com.tns.NativeScriptException: 
Calling js method onStart failed
TypeError: Cannot read property 'getViewTreeObserver' of undefined
File: "/data/data/ba.fkzeljeznicar/files/app/tns_modules/ui/scroll-view/scroll-view.js, line: 125, column: 21

This one appears to be caused by the ScrollView implemented in views/home/home.xml.
To reproduce the crash open the app >> navigate to "more" >> minimize the app >> return back to the app >> the app will throw with this error (in debug mode) or will simply exit in production.

The reason for this to happen is because the scroll view is not yet initialized on view loaded event. I am guessing that the partials loaded inside causing this behavior as I was unable to reproduce it in a local project with the same scenario, however the fix was pretty easy - I've made some structural changes as follows:
in your home.xml

<ScrollView loaded="viewLoaded" ios.showsVerticalScrollIndicator="false" xmlns:fkz="views/home/">
    <StackLayout>
        <fkz:partial-articles marginTop="66"/>
        <fkz:partial-matches />
        <fkz:partial-video />
        <fkz:partial-sponsor /> 
        <fkz:partial-articles-rest />
    </StackLayout>     
</ScrollView>

Now that the ScrollView has guarantied single parent and is our root element there were also some minor changes in viewLoaded as follows:
home.js

exports.viewLoaded = function(args){
var dashScrollView = args.object; 
// this is now the ScrollView as we are using its loaded event
// so no need of getViewById
...
}

@manijak

@manijak regarding the OOM issue from java.lang.OutOfMemoryError (dalvik.system.VMRuntime.newNonMovableArray).txt

java.lang.OutOfMemoryError: Failed to allocate a 2805772 byte allocation with 2547104 free bytes and 2MB until OOM

As suggested by @NathanaelA and @Pip3r4o you can manually trigger garbage collector and also take advantage of the android flags set in app/package.json to trigger the cleanup of memory on some time interval. Keep in mind that the global.GC() will trigger the JavaScript garbage collector only and not the JAVA one. You can combine both tactics to force the cleanup in your project.
e.g.
open your application package.json (not the root one but the one located in your app folder)
app/package.json

"android": {
	"v8Flags": "--expose_gc",
	"memoryCheckInterval": 500,
	"freeMemoryRatio": 0.50
},

The best explanation what this will do can be found here

Also as @NathanaelA mentioned you can trigger the JavaScript GC on key points in your application (for example when the user is leaving a heavy-duty image page) with

exports.onUnloaded = function(args){
    console.log("view unloaded");

    if (global.android) {
        global.gc();
    }
}

After combining both techniques and monitoring the memory usage resulted taht the application memory has been now stable and is freed on some time interval.
I've used adb dumpsys to check the memory usage.

adb shell dumpsys meminfo | grep ba.fkzeljeznicar.fkzeljoapp

@NickIliev

Thank you @NickIliev . This is very helpful. Have already managed to reproduce the crash above and fixed it. Altho I am curious on how you managed to find out that the issue was located in the home.xml view? The stacktrace didn't have any mention of it or any of my files.

Also thanks for the gc tips. Very helpful. Do the same rules apply for iOS? I have not had any issues reported from iOS users, nor anything logged in analytics.

@manijak

@manijak for iOS you can trigger the GC following these instructions but you should use this carefully as it might lead to side effects. Overall in iOS memory usage problems are much harder to achieve so you won't need to manually handle it.

As for the issue in home.xml - I've noticed that the error is thrown at this line (the log shows the same line in the transpiled JS file but this is the corresponding one in the source TS file) so I've simply started to "turn off" all scroll views in the app until the error was no longer reproducible.

As for the other error logs - I am currently unable to reproduce them at my side - only once I got a page transition problem but it was inconsistent and does not re-appear. If you come to a stable way to hit one of those please let me know.

I was just testing the memory management tips you guys provided. I updated app/package.json and included the memorycheck parts. Also added two global.GC(); calls in two different views (article & player-details).

Started up the app, and just tapped around, article 1, article 2, match-details, tab2, tab3, tab4, then lastly player-details. As soon as I tapped back, before it managed to hit unloaded I get the exception below. Could this be the one you were after? I managed to get it two times in a row, but it's not consistent. It needs to reach a certain memory threshold I guess...

I think issue here is that my main-view (TabView) contains a lot of complex partial-views (for each tab).
And that is where most of the memory goes. Would it be wise to force GC when leaving the main-view?

*** StackTrace *** : An uncaught Exception occurred on "main" thread.
java.lang.OutOfMemoryError: Failed to allocate a 2188332 byte allocation with 1938816 free bytes and 1893KB until OOM
	at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
	at android.graphics.Bitmap.nativeCreate(Native Method)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:831)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:808)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:775)
	at android.transition.TransitionUtils.createViewBitmap(TransitionUtils.java:165)
	at android.transition.TransitionUtils.copyViewImage(TransitionUtils.java:102)
	at android.transition.Visibility.onDisappear(Visibility.java:384)
	at android.transition.Visibility.createAnimator(Visibility.java:247)
	at android.transition.Transition.createAnimators(Transition.java:732)
	at android.transition.TransitionSet.createAnimators(TransitionSet.java:405)
	at android.transition.Transition.playTransition(Transition.java:1777)
	at android.transition.TransitionManager$MultiListener.onPreDraw(TransitionManager.java:306)
	at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:944)
	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2055)
	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1107)
	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:6013)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:858)
	at android.view.Choreographer.doCallbacks(Choreographer.java:670)
	at android.view.Choreographer.doFrame(Choreographer.java:606)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:844)
	at android.os.Handler.handleCallback(Handler.java:739)
	at android.os.Handler.dispatchMessage(Handler.java:95)
	at android.os.Looper.loop(Looper.java:148)
	at android.app.ActivityThread.main(ActivityThread.java:5417)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

And the third time I got this one. This is what concerns me, they are so random and sometimes different from one another....

 *** StackTrace *** : An uncaught Exception occurred on "main" thread.
  com.tns.NativeScriptException: No weak reference found. Attempt to use cleared object reference id=22458
		at com.tns.Runtime.getJavaObjectByID(Runtime.java:971)
		at com.tns.Runtime.callJSMethodNative(Native Method)
		at com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1197)
		at com.tns.Runtime.callJSMethodImpl(Runtime.java:1061)
		at com.tns.Runtime.callJSMethod(Runtime.java:1047)
		at com.tns.Runtime.callJSMethod(Runtime.java:1028)
		at com.tns.Runtime.callJSMethod(Runtime.java:1018)
		at com.tns.gen.android.transition.Transition_TransitionListener.onTransitionEnd(android.transition.Transition$TransitionListener.java)
		at android.transition.Transition.end(Transition.java:1924)
		at android.transition.Transition$3.onAnimationEnd(Transition.java:1875)
		at android.animation.ValueAnimator.endAnimation(ValueAnimator.java:1239)
		at android.animation.ValueAnimator$AnimationHandler.doAnimationFrame(ValueAnimator.java:766)
		at android.animation.ValueAnimator$AnimationHandler$1.run(ValueAnimator.java:801)
		at android.view.Choreographer$CallbackRecord.run(Choreographer.java:858)
		at android.view.Choreographer.doCallbacks(Choreographer.java:670)
		at android.view.Choreographer.doFrame(Choreographer.java:603)
		at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:844)
		at android.os.Handler.handleCallback(Handler.java:739)
		at android.os.Handler.dispatchMessage(Handler.java:95)
		at android.os.Looper.loop(Looper.java:148)
		at android.app.ActivityThread.main(ActivityThread.java:5417)
		at java.lang.reflect.Method.invoke(Native Method)
		at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
		at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)

@manijak

@manijak the reason we are not encouraging the usage of GC by default and why the GCs are not publicly exposed is because when triggering manually the Garbage Collector, it can "collect" items that are not supposed to be collected at this very moment leading to the last error log No weak reference found. Attempt to use cleared object reference. I am still debugging your application in order to find a better solution that excludes the manual usage of GC and will let you know if I have a better solution.

As for the first error - the Java garbage collector can not be forced on specific JavaScript line - so even if you call it in your unloaded it is not guaranteed that it will be triggered explicitly at this moment. You can try the different approaches when using the Java GC including changing the freeMemoryRatio (values from 0(disabled) to 1(full)) or using the gcThrottleTime as shown in this article

@NickIliev

@NickIliev article link is broken

@manijak

@manijak I've noticed that the plugin nativescript-web-image-cache has a cache clearing method. Perhaps you can try to manually clear the cache (when needed) using the plugin preferable to calling the GC.

var imageCacheModule=require("nativescript-web-image-cache");
imageCacheModule.clearCache();

@NathanaelA you are right! Calling GC() is not the reason for the no weak ref. We have succeeded of stability reproducing this error and currently, Pip3r4o is investigating it.

@NickIliev

@NickIliev Yeah I've tried that before (also just now), it didn't have any major impact on memory and I received a OOM at the end. It freed up between 500-2000 kb in total.

The biggest jumps in memory seem to be when I go back to main-view from another Page. And also when switching Tabs.

I don't know, but I feel that calling clearCache() too often would defeat the purpose of it.

@manijak

@manijak Thanks for your elaborate report on the findings! We aren't sure yet why the Repeater causes so many problems, I only knew that it was the Repeater all along, even if the bound property was empty, or when it contained few elements.

As an alternative to the Repeater component, which I believe you use only to list items horizontally - you could use the nativescript-telerik-ui's RadListView whose orientation can be set to suit your needs. I understand that will increase the application size slightly, but it might be worth a shot!

@NathanaelA

@NathanaelA - please allow me to disagree with you on that.
The link that you have provided lists issues on the NativeScript UI's public repository which people use for various reasons, many of which are simply handicaps that they have hit while developing but which were later resolved. They were not even bugs with the component. Other people report stuff and stop sharing information after some time, especially when it comes to reproducing a problem they report. They might simply have resolved it. We do not close all off the issues as they might be helpful for people having similar cases. It is, to say the least, pretty superficial to judge based on that. Moreover, some of the issues you see there are simply logged by us to inform people what we're working/planning to work on for the near future. On top of that, many of the issues in the Feedback repository were migrated from the SDK Samples repositories by ourselves when we decided that we will stop using them for feedback from customers. They contain useful information and that is why we decided not to close them.

As for your experience with using RadListView - we have a couple of statements to make:

we have thoroughly reviewed your reports and have addressed issues that we were able to reproduce
in our internal issue tracking system there are a bunch of issues that are addressed and closed during the last several months
we are taking RadListView pretty seriously as the backbone of every mobile app and thus are treating issues related to it with highest priority

For example, our next major effort is enabling Grouping, Filtering and Sorting as it was previously postponed due to various reasons.

If you think there are still pending issues with RadListView that make it difficult to use, please let us know by providing enough information for us to reproduce.

I also think it has something to do with transitions or animations. I just re-added all my Repeaters, but removed animated transitions when navigating to other views.

The app did not crash once, it didn't even OOM. App also ran smoother, faster. But it looks awful when switching views... Very interesting.

Regarding the RLV, thanks for the heads up. I own the pro/licensed version of nativescript-ui and it just doesn't suit my needs for now. Not until each component is split into its own plugin. I do not want to bloat my app needlessly.

@manijak

@manijak - separating the components sounds reasonable. The first step would probably be to separate the List and SideDrawer as they are the most popular ones.

This looks like a transition listener that got prematurely collected:
com.tns.gen.android.transition.Transition_TransitionListener.onTransitionEnd

@manijak

@manijak Is the issue with

 No weak reference found. Attempt to use cleared object reference id=20194
JS:     at com.tns.Runtime.getJavaObjectByID(Runtime.java:825)
...
com.tns.gen.android.transition.Transition_TransitionListener.onTransitionEnd(Transition_TransitionListener.java:17)
JS:     at android.transition.Transition.end(Transition.java:1924)

still reproducible?

@hshristov

@hshristov To be honest, our app is still on version 2.4 of TNS. We are planning to release a new version around the holidays that will be based on 3.4. Will report back on the outcome.

(But I have not seen this error for a while when testing via emulators)

I can reproduce it, the key is to navigate quickly between screens, I use navigation other than fade though, maybe the fade transition "hides" the issue

Closing due to inactivity

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Navigation Menu

Repository navigation

[Android] Production app crashing in runtime #3901

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Android] Production app crashing in runtime #3901

Description

Activity

NathanaelA commented on Mar 29, 2017

NickIliev commented on Mar 30, 2017

petekanev commented on Mar 30, 2017

manijak commented on Mar 30, 2017

NickIliev commented on Mar 30, 2017

NickIliev commented on Mar 30, 2017

manijak commented on Mar 30, 2017

NickIliev commented on Mar 31, 2017

manijak commented on Mar 31, 2017

NickIliev commented on Mar 31, 2017

danielgek commented on Mar 31, 2017

NathanaelA commented on Mar 31, 2017

NickIliev commented on Apr 3, 2017

manijak commented on Apr 3, 2017

15 remaining items

petekanev commented on Jun 13, 2017

NathanaelA commented on Jun 13, 2017

ginev commented on Jun 14, 2017

NathanaelA commented on Jun 14, 2017

NathanaelA commented on Jun 14, 2017

manijak commented on Jun 14, 2017

ginev commented on Jun 15, 2017

PanayotCankov commented on Aug 4, 2017

hshristov commented on Dec 20, 2017

manijak commented on Dec 20, 2017

Tronix117 commented on Mar 23, 2018

NickIliev commented on Aug 7, 2018

lock commented on Aug 26, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions