Nativescript-ui-feedback: RadListView (RLV) memory leak

[dropclick]

Tell us about the problem

Heap memory allocated by RadListView instances is never fully released during garbage collection.

Which platform(s) does your issue occur on?

iOS 12.2
Android 25+

Please provide the following version numbers that your issue occurs with:

• Progress NativeScript UI plugin version: 6.3.0
• CLI: 5.2.0
• Cross-platform modules: 5.4.0
• Runtime(s): 5.4.0

Please tell us how to recreate the issue in as much detail as possible.

I tried to isolate the problem in this demo app.

Please download the app and then do the following to reproduce the issue on iOS:

1. Run tns install
2. Run tns build ios --for-device --release
3. Open platforms/ios in XCode
4. Select Product > Profile
5. Choose Allocations
6. Start recording
7. Select All Heap Allocations in the allocations list
8. Navigate between pages Home and Test several times
9. Watch how heap memory allocations increase around 25 MB each time you navigate to Test page (this is expected behaviour, because every time an instance of the page is added to the navigation history stack)
10. On Home page click on Navigate to Test Component and clear history
11. Navigate back to Home page, tap/click on Collect garbage and see that heap allocations do not decrease

If you replace RadListView with ListView in test.component.html the described behaviour changes as follows:

• Heap allocations increase around 1 MB each you navigate from Home to Test
• When you do steps 10 und 11 the garbage collector works as expected

The problem also exists on Android. I tested the above in Android Studio and the result is the same.

Similar problems have already been reported in #822, #825 and #6234.

[tsonevn]

Hi @dropclick,
Thank you for reporting this issue. We were able to recreate it and will investigate it further. For now, I would suggest keeping track on the issue for further info.

I am also attaching the version of the project without lazy loading, where the issue is still reproducible.
Archive.zip

[mandar-bhong]

I am facing the similar issue in my development environment
When debugging application with tns debug android, application on system is consuming about 2 GB first time. After making changes in the application recompile happens and with every compilation about 500 MB memory increases each time on top of 2 GB. After few changes we are not able to work as memory reaches to its peak and application restart required to debug further.

Windows 8.1

√ Getting environment information

No issues were detected.
√ Your ANDROID_HOME environment variable is set and points to correct directory.

√ Your adb from the Android SDK is correctly installed.
√ The Android SDK is installed.
√ A compatible Android SDK for compilation is found.
√ Javac is installed and is configured properly.
√ The Java Development Kit (JDK) is installed and is configured properly.
√ Local builds for iOS can be executed only on a macOS system. To build for iOS
on a different operating system, you can use the NativeScript cloud infrastructure.
√ Getting NativeScript components versions information...
√ Component nativescript has 5.4.0 version and is up to date.

C:\Users\Mandar>tns info
√ Getting NativeScript components versions information...
√ Component nativescript has 5.4.0 version and is up to date. (Latest version released on June 4,19)

package.json
{
"android": {
"markingMode": "none"
},
"nativescript": {
"id": "com.xxx.xxx",
"tns-ios": {
"version": "5.0.0"
},
"tns-android": {
"version": "5.4.0"
}
},
"scripts": {
"androiddebug": "node --max_old_space_size=4096 tns debug android --bundle"
},
"description": "NativeScript Application",
"license": "SEE LICENSE IN ",
"repository": "",
"dependencies": {
"@angular/animations": "8.0.0",
"@angular/common": "8.0.0",
"@angular/compiler": "8.0.0",
"@angular/core": "8.0.0",
"@angular/forms": "8.0.0",
"@angular/http": "8.0.0-beta.10",
"@angular/platform-browser": "8.0.0",
"@angular/platform-browser-dynamic": "8.0.0",
"@angular/router": "8.0.0",
"mime-types": "^2.1.22",
"moment": "^2.24.0",
"nativescript-angular": "^8.0.0",
"nativescript-background-http": "^3.4.0",
"nativescript-camera": "^4.1.1",
"nativescript-cardview": "^3.1.1",
"nativescript-cfalert-dialog": "^1.0.14",
"nativescript-drawingpad": "^3.0.4",
"nativescript-fancyalert": "^3.0.6",
"nativescript-imagepicker": "^6.0.4",
"nativescript-local-notifications": "^3.1.0",
"nativescript-ripple": "^2.1.0",
"nativescript-snackbar": "^4.0.0",
"nativescript-sqlite": "^2.2.3",
"nativescript-theme-core": "~1.0.4",
"nativescript-toast": "^2.0.0",
"nativescript-ui-autocomplete": "^3.11.0",
"nativescript-ui-chart": "^3.10.0",
"nativescript-ui-listview": "^5.0.0",
"nativescript-ui-sidedrawer": "^6.0.0",
"nativescript-websockets": "^1.5.3",
"reflect-metadata": "~0.1.8",
"rxjs": "^6.3.3",
"tns-core-modules": "^5.4.1",
"tns-platform-declarations": "^5.1.1",
"typescript": "~3.1.1",
"zone.js": "^0.8.4"
},
"devDependencies": {
"@angular/compiler-cli": "~7.2.0",
"@nativescript/schematics": "~0.4.0",
"@ngtools/webpack": "~7.2.0",
"nativescript-dev-typescript": "^0.10.0",
"nativescript-dev-webpack": "^0.22.0",
"ts-loader": "^5.3.1"
},
"readme": "NativeScript Application"
}

[VladimirAmiorkov]

Hi @dropclick @mandar-bhong ,

Can you confirm that this issue is only observed on iOS?

[tschuller-TBIT]

Hi @VladimirAmiorkov,

we observed the Issue on both IOS and Android as dropclick mentioned in his post at the end:

"The problem also exists on Android. I tested the above in Android Studio and the result is the same."

[mandar-bhong]

Hi @VladimirAmiorkov,
I have tested it with nativescript-cli and VSCode for android

[VladimirAmiorkov]

Thank you for the update. I was able to observe the issue on Android using Chrome Devtool. Inside Android Studio, profiling the native elements I was not able to reproduce it tho so it looks like to be a JavaScript object issue. We will update you once we have more details.

[mandar-bhong]

Please keep eyes on the development system memory is getting increases each as mentioned.

How we can make sure that it is JavaScript object issue which every time increases my system memory and how to debug it.
Please suggest on this
Thanks

[VladimirAmiorkov]

There are two ways to profile the memory of an NativeScript app:

• When looking for native objects that are not cleared you should use Android Studio and XCode as you would if you were developing a pure native app
• Because NativeScript has a JS running inside the native app it is possible that the JS objects that either have or do not have a native counterpart can also be retained and not cleared during GC. To profile the JS you can use Chrome Devtools for Android (tns debug android) and the Inspect for iOS (tns debug ios --inspect)

In many cases a JS leak could be the cause of a native object not being released during GC and vice versa, it all depends on the implementation. Hunting memory issues is not always straight forward so be careful and patient :)

[VladimirAmiorkov]

FYI, we are currently working on resolving this issue so stay tuned for further information.

[VladimirAmiorkov]

Update:

• We have resolved and issue that was causing memory leak on iOS inside the nativescript-ui-listview code and a new version is due to be released.
• Regarding the observed issue on Android it is caused by an issue in the tns-core-modules package and there is a PR that should resolve it. You can track it here.

In order for this issue to be marked as close both a new version of nativescript-ui-listview and tns-core-modules needs to be released.

[dropclick]

@VladimirAmiorkov Thanks for update. Indeed the garbage collection does now work when swipe actions are disabled. However, when I activate swipe actions the garbage collection still does not work.

[dropclick]

I updated the demo app so you can reproduce my issue.

[zbranzov]

The fix is released in [email protected]

[zbranzov]

@dropclick Would you try the latest version and let us know whether the issue persists?

[tschuller-TBIT]

I don't see any difference here on my side with list view 6.4.2, neither automatic gc nor manual gc seems to be working:

[dropclick]

@zbranzov Thanks for the update. I updated the demo app to use [email protected]. Unfortunately the problem still exists in version 6.4.2 as @tschuller-TBIT already pointed out.

[dottodot]

I have a issue were my app completely crashes after navigating to a list view, 6.4.0 is OK and this is the only change in 6.4.1 so have to assume it's something to do with this. Not getting errors which is strange but reverting back to 6.4.0 allows my app to work.

[tschuller-TBIT]

Do you have more information about how you use that ListView in detail at that point and what the error message is?

[dottodot]

I'm not getting an error my app just becomes completely unresponsive. I've narrowed it down to having a search bar in list view header as per below, any idea as to why it no longer works?

    <ng-template tkListViewHeader>
      <GridLayout rows="auto, *">
        <SearchBar class="m-b-10" row="1" hint="Search by context no" [text]="searchPhrase"
          (textChange)="onTextChanged($event)" (submit)="onSubmit($event)" backgroundColor="#f3f4ee" color="black"
          textFieldBackgroundColor="white" textFieldHintColor="black" (loaded)="searchBarLoaded($event)"></SearchBar>
      </GridLayout>
    </ng-template>

[tschuller-TBIT]

There seem to be some Bugs in new ListViewUI Modules (Version 6.4.1 + 6.4.2) in specific use cases, I had problems with search bars in RLV too, but I got the following error message:

NativeScript caught signal 11.
Native Stack:
1   0x106ae01df sig_handler(int)
2   0x10b9d2b5d _sigtramp
3   0x12c200030
4   0x109e4120f -[TKListViewLinearLayout getItemSizeForIndexPath:]
5   0x109e4074f -[TKListViewLinearLayout initItemAttributes:atPoint:lastInSection:]
6   0x109e3f465 -[TKListViewLinearLayout layoutSection:atPoint:]
7   0x109e3a057 -[TKListViewLinearLayout layoutSections]
8   0x109e39d0e -[TKListViewLinearLayout prepareLayout]
9   0x10bdb30ee -[UICollectionViewData _prepareToLoadData]
10  0x10bdb5ebe -[UICollectionViewData collectionViewContentRect]
11  0x10bd768bf -[UICollectionView setFrame:]
12  0x10c9b240a -[UIView(Geometry) _applyAutoresizingMaskWithOldSuperviewSize:]
13  0x10c9b3331 -[UIView(Geometry) _resizeWithOldSuperviewSize:]
14  0x10c8f4dd8 -[UIScrollView(_UIOldConstraintBasedLayoutSupport) _resizeWithOldSuperviewSize:]
15  0x10afe6013 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:]
16  0x10c9b1d6b -[UIView(Geometry) resizeSubviewsWithOldSize:]
17  0x10c9b03e8 -[UIView(Geometry) setFrame:]
18  0x109e4bcfc -[TKListView setFrame:]
19  0x10c9b240a -[UIView(Geometry) _applyAutoresizingMaskWithOldSuperviewSize:]
20  0x10c9b3331 -[UIView(Geometry) _resizeWithOldSuperviewSize:]
21  0x10afe6013 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:]
22  0x10c9b1d6b -[UIView(Geometry) resizeSubviewsWithOldSize:]
23  0x10c9b03e8 -[UIView(Geometry) setFrame:]
24  0x1073fc51d ffi_call_unix64
25  0x13a32c100
JS Stack:
1   setFrame@[native code]
2   _setNativeViewFrame@file:///app/tns_modules/tns-core-modules/ui/core/view/view.js:133:27
3   layoutNativeView@file:///app/tns_modules/tns-core-modules/ui/core/view/view.js:165:33
4   layout@file:///app/tns_modules/tns-core-modules/ui/core/view/view.js:66:34
5   layoutChild@file:///app/tns_modules/tns-core-modules/ui/core/view/view-common.js:908:21
6   @file:///app/tns_modules/tns-core-modules/ui/layouts/stack-layout/stack-layout.js:112:51
7   eachLayoutChild@file:///app/tns_modules/tns-core-modules/ui/layouts/layout-base-common.js:143:21
8   layoutVertical@file:///app/tns_modules/tns-core-modules/ui/layouts/stack-layout/stack-layout.js:110:29
9   onLayout@file:///app/tns_modules/tns-core-modules/ui/layouts/stack-layout/stack-layout.js:82:32
10  layout@file:///app/tns_modules/tns-core-modules/ui/core/view/view.js:74:26
11  layoutChild@file:///app/tns_modules/tns-core-modules/ui/core/view/view-common.js:908:21
12  onLayout@file:///app/tns_modules/tns-core-modules/ui/page/<…>

In one View the List was wrapped inside a "*ngIf"-condition on an initialization flag, removing the condition solved the problem, but I don't know why...
In another View, similar use case, I could not resolve the issue at all and switched to classic ListView instead of RLV, but this is just possible if you do not need swipe events or reordering!

(It is more than unfortunate, that the feature richest and I guess most used view component of the framework is making that much problems, at the moment it can't be really used in my opinion...)

[felixkrautschuk]

@dottodot maybe you should open a separate issue for your problem on Github, as this issue deals with a memory leak

[dottodot]

@felix-idf I only posted in this issue and as far as I can tell the changes made for memory leaks have resulted in my issue as they have been then only changes.

[gregersen79]

I'm having the same issue as @tschuller-TBIT posted (only on iOS), with RLV 6.4.1 and 6.4.2.
App crashes with the following report:

NativeScript caught signal 11.
Native Stack:
1   0x101054f70 sig_handler(int)
2   0x219cb99dc <redacted>
3   0x102215918 -[TKListView collectionView:cellForItemAtIndexPath:]
4   0x24615de7c <redacted>
5   0x246161f34 <redacted>
6   0x2461668f4 <redacted>
7   0x246d02ed0 <redacted>
8   0x21e55da20 <redacted>
9   0x21e5629c8 <redacted>
10  0x246ceef04 <redacted>
11  0x102212cc0 -[TKListView reloadData]
12  0x101ac4044 ffi_call_SYSV
13  0x101ac0eb4 ffi_call_int
14  0x101ac09b0 ffi_call
15  0x100fdcf90 NativeScript::FunctionWrapper::call(JSC::ExecState*)
16  0x101abfa58 llint_entry
17  0x101abee4c llint_entry
18  0x101abee4c llint_entry
19  0x101abee4c llint_entry
20  0x101abee4c llint_entry
21  0x101abee4c llint_entry
22  0x101abeeb4 llint_entry
23  0x101ab791c vmEntryToJavaScript
24  0x1018b684c JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
25  0x1010c2b20 JSC::callSetter(JSC::ExecState*, JSC::JSValue, JSC::JSValue, JSC::JSValue, JSC::ECMAMode)
26  0x101147910 JSC::JSObject::putInlineSlow(JSC::ExecState*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&)
27  0x101141adc JSC::JSObject::put(JSC::JSCell*, JSC::ExecState*, JSC::PropertyName, JSC::JSValue, JSC::PutPropertySlot&)
28  0x10195b2bc llint_slow_path_put_by_val
29  0x101abb6ec llint_entry
30  0x101abee4c llint_entry
31  0x101abee4c llint_entry
JS Stack:
1   reloadData@[native code]
2   refresh@file:///app/tns_modules/nativescript-ui-listview/ui-listview.js:1508:48
3   onItemsChangedInternal@file:///app/tns_modules/nativescript-ui-listview/ui-listview.common.js:762:21
4   onItemsChanged@file:///app/tns_modules/nativescript-ui-listview/ui-listview.common.js:765:36
5   onItemsPropertyChanged@file:///app/tns_modules/nativescript-ui-listview/ui-listview.common.js:665:28
6   valueChanged@file:///app/tns_modules/nativescript-ui-listview/ui-listview.common.js:998:42
7   set@file:///app/tns_modules/tns-core-modules/ui/core/properties/properties.js:108:37
8   set@file:///app/tns_modules/tns-core-modules/ui/core/view-base/view-base.js:221:13
9   updateOptions@file:///app/tns_modules/tns-core-modules/ui/core/bindable/bindable.js:487:36
10  updateTarget@file:///app/tns_modules/tns-core-modules/ui/core/bindable/bindable.js:421:27
11  update@file:///app/tns_modules/tns-core-modules/ui/core/bindable/bindable.js:155:30
12  bindingContextChanged@file:///app/tns_modul<\M-b\M^@\M-&>

I narrowed it down to a GridLayout container above my RLV. If I comment out that GridLayout it works. So for now I'm stuck on version 6.4.0

[VladimirAmiorkov]

Hi @gregersen79 @tschuller-TBIT ,

Can I ask you to post your issues in a separate thread in which to follow the "issue template" and give us all the required details. This way we can make sure that we are investigating the correct case and not simply guessing what your exact scenario is, also this will make sure this thread is kept to its original point which was memory issues.

Thank you.

[VladimirAmiorkov]

Hi @tschuller-TBIT @dropclick,

I am closing this thread because the original issue has been resolved with the 6.4.2 version. After that release the test project with which the issue was reported has been changed to include a difference scenario that was not original reported which unfortunately again brings memory issues. I have moved that issue here in order to better track its process and to make sure that this thread is not being used for reporting multiple issues and use cases causing the thread to blowup and be unusable.

Please continue your discussion here and make sure you follow it for future updates.