[Marking Mode: None]: Crash: Attempt to use cleared object reference

[daveware-nv]

Please, provide the details below:

Via crashlytics we have been getting reports of crashes of the type
com.tns.NativeScriptException: Attempt to use cleared object reference id=48048(com.tns.NativeScriptException: Attempt to use cleared object reference id=48048 com.tns.Runtime.getJavaObjectByID(Runtime.java:893)

Did you verify this is a real problem by searching Stack Overflow and the other open issues in this repo?

Other closed bugs reference the same or similar issues (latest was closed for 3.0.0).

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

• CLI: 3.2.1
• Cross-platform modules: 3.2.0
• Runtime(s): 3.2.0
• Plugin(s):
• • nativescript-angular: 4.4.1
• • nativescript-fabric: 0.3.1
• • nativescript-pro-ui: 3.2.0
• • nativescript-google-maps-sdk: 2.3.3

Built using webpack (npm run ns-bundle --android --build-app --snapshot --clean --release)
Also using in app/package.json:

  "android": {
    "v8Flags": "--expose_gc",
    "markingMode": "none"
  }

Did the error happen while the app was being constructed? (buildtime error)

No

Did the error happen while the app was executing? (runtime error)

Yes, but I haven't reproduced it myself. Just numerous similar stack traces being sent via crashlytics/fabric.

e.g.

#0. Crashed: main: 0 0 0x0000000000000000
       at .Error: com.tns.NativeScriptException: Attempt to use cleared object reference id=48048(com.tns.NativeScriptException: Attempt to use cleared object reference id=48048
    com.tns.Runtime.getJavaObjectByID(Runtime.java:893)
    com.tns.Runtime.callJSMethodNative(Native Method)
    com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1084)
    com.tns.Runtime.callJSMethodImpl(Runtime.java:966)
    com.tns.Runtime.callJSMethod(Runtime.java:953)
    com.tns.Runtime.callJSMethod(Runtime.java:937)
    com.tns.Runtime.callJSMethod(Runtime.java:929)
    com.tns.gen.java.lang.Runnable.run(Runnable.java:10)
    android.os.Handler.handleCallback(Handler.java:751)
    android.os.Handler.dispatchMessage(Handler.java:95)
    android.os.Looper.loop(Looper.java:154)
    android.app.ActivityThread.main(ActivityThread.java:6780)
    java.lang.reflect.Method.invoke(Native Method)
    com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1496)
    com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1386):1)
       at . ... (repeats with slight differences)

full trace at https://pastebin.com/JEGTYrpx

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

Unknown. Possibly random.

[Plamen5kov]

Hi @daveware-nv, we're going to be able to better assist you if you provide steps to reproduce, with the minimal code required or a small repo for us to check out.
Having said that, can you give us the content of your projects' package.json so we can check out the plugins you're using.
The problem occurs when a javascript object with a native counterpart isn't taken care of by the developer, since marking mode=none doesn't check which js objects have a native counterpart and should survive GC and which don't.

[daveware-nv]

As mentioned I don't know when it occurs as I haven't observed it myself, nor as a result do I know what the minimal code required to reproduce would be.

snippets from the package.json:

  "dependencies": {
    "nativescript-angular": "~4.4.1",
    "nativescript-angular-snapshot": "3.0.0-5.5.372.32",
    "nativescript-couchbase": "custom-see-below",
    "nativescript-fabric": "^0.3.0",
    "nativescript-google-maps-sdk": "^2.3.2",
    "nativescript-pro-ui": "~3.2.0",
    "nativescript-svg": "^1.1.3",
    "nativescript-theme-core": "~1.0.2"
},
"devDependencies": {
    "nativescript-css-loader": "~0.26.0",
    "nativescript-dev-android-snapshot": "0.*.*",
    "nativescript-dev-typescript": "~0.4.0",
    "nativescript-dev-webpack": "^0.8.0",
    "nativescript-worker-loader": "~0.8.1",
}

notes:

• Despite nativescript-svg being present I don't think we're actually actively using it.
• For nativescript-couchbase we're using a custom version derived from 1.0.17
• We also have a purely custom plugin for doing some bluetooth interaction
• There's probably also direct references to android bits here and there in the application itself, including producing some uuid's using java.util.UUID.randomUUID().toString().

Is there some detailed documentation on what 'taken care of by the developer' means in you above post? The only reference I've seen to markingMode: none is the 3.2 announcement blog post and it wasn't detailed enough on what is required to prevent markingMode: none causing problems.

We have a lot of data going into and out of couchbase, so depending on what care needs to be taken with which kinds of java objects that may be the first place for me to look once I know what to look for.

[Plamen5kov]

@daveware-nv

...once I know what to look for

The simplest way for me to explain what to look for. Consider this scenario in your code or in some native plugin you're using (there's a big chance the problem is in the plugin, as the currently available plugins aren't meant to be used in conjunction with markingMode: none.

problem

var implementor = new android.native.Implementor()
var callback = new android.native.NCallback({
	getMessage: function() {
		implementor.getMessage()
	}
})
android.native.Executor.printWithDelay(callback, 3s)

pseudo code

• android.native.Implementor : native class
• android.native.NCallback : native interface

The implementor is enclosed by the callback implementation, but with markingMode: none enabled we no longer take care of finding that connection out. So when GC happens implementor instance is GC`ed.

solution
to fix the previous example you must keep implementor from being GC'ed, by attaching it to the global object which is not being GC'ed ever, or some other long-lasting object, exported module or wherever you see fit. (implementor is attached to global is just for the sake of the example).

var implementor = new native.Implementor()
global.implementor = implementor
var callback = new native.NCallback({
	getMessage: function() {
              global.implementor.getMessage()
	}
})
native.Executor.printWithDelay(callback, 3s)

pseudo code

summary
Every native object instantiated in JS:
var implementor = new android.native.Implementor()
which is enclosed by a function of an extended class, or enclosed up it's prototype chain:

...
	getMessage: function() {
		implementor.getMessage()
	}
...

needs to be managed by the developer. You should decide when it should be not used anymore and can be let go for GC.

[Plamen5kov]

We haven't got a blog post about it because it's an experimental flag, and we're still contemplating on trying it out. We wanted to check out what kinds of problems developers would encounter, so we get a better understanding of the user scenarios.

[daveware-nv]

Thanks. If that is the extent of it, then it should be less of a problem to track things down in my code than I expected. Less easy are nativescript-pro-ui since it does not have source available. And nativescript-angular since my app is an angular one this will be used heavily by every screen (and a quick look though the stacktrace I posted above reveals EmulatedRenderer.NativeScriptRenderer.insertBefore, which I believe corresponds to this line https://github.com/NativeScript/nativescript-angular/blob/42e438ce4b206ff96fb2fe31e9968fcfc555f5a6/nativescript-angular/renderer.ts#L101)

Unfortunately markingMode: none makes a huge difference. Otherwise I would have never deployed with it in the first place, and could simply turn it off now. The random multi-second (and sometimes minutes) long UI freezes did not make for a good user experience.

[Plamen5kov]

@daveware-nv, did you manage to fix your issue or are you still trying to figure out where the problem is?

[daveware-nv]

Unfortunately I haven't had time to complete my sweep yet. And I probably wont know for sure whether any changes made fixed everything until we make another release, since the crashing hasn't really shown up during test usage.

I have established some candidates to clean up however:

• There's one that looks especially fishy in the couchbase plugin.
• I've got some nativescript -> java interface implementations in my bluetooth plugin. But it doesn't reference java objects that aren't passed as parameters (are JS objects fine here? I'd assume at he very least the error would be different).
• There's also some java objects being returned from the bluetooth plugin that I'll have to trace the path of more thoroughly.
• I still have yet to look at the google maps plugin.

And of course then there is nativescript-angular and nativescript-pro-ui, which I wouldn't know where to start looking, do you know if these have been vetted similar to tns-core-modules?

[Plamen5kov]

And of course then there is nativescript-angular and nativescript-pro-ui, which I wouldn't know where to start looking,

Both plugins are usable with the current version of the android runtime, but they are not compatible with markingMode: none at least not yet.

I've got some nativescript -> java interface implementations in my bluetooth plugin. But it doesn't reference java objects that aren't passed as parameters (are JS objects fine here? I'd assume at he very least the error would be different).

It doesn't really matter if the javascript objects with the native counterparts are passed as a parameter or not, except for their life duration. Unfortunately, the error you saw, will be the same no matter if the parameters are passed as arguments to a function or not.

[daveware-nv]

Both plugins are usable with the current version of the android runtime, but they are not compatible with markingMode: none at least not yet.

That is unfortunate, that probably makes my efforts (and yours) here moot for the time being. So I'll probably have to advise the project owner that markingMode: none isn't supported for our applications dependencies, and see if they want to persist here or not. Do you know what the timeframe (if any) for supporting markingMode: none for those plugins is?

It doesn't really matter if the javascript objects with the native counterparts are passed as a parameter or not, except for their life duration. Unfortunately, the error you saw, will be the same no matter if the parameters are passed as arguments to a function or not.

I was mostly implying that since they are passed as parameters there must be a reference to them somewhere else (not just the method where I'm defining my interface implementation) on the stack, and hence where responsibility for managing the references to the native object are. The other thing I was asking was whether pure javascript objects can also get GC'd early across this boundary?

[Plamen5kov]

Do you know what the timeframe (if any) for supporting markingMode: none for those plugins is?

We've not settled on using markingMode:none by default yet, because we're still trying out GC algorythms that wouldn't ask the developer to take care of the objects' lifetime and still be more performant than what we currently have. Unfortunately I can't give you a timeframe, because it's a very fundamental matter and needs a measure of trial and error.

The other thing I was asking was whether pure javascript objects can also get GC'd early across this boundary?

Pure js objects are dealt with entirely by V8's GC. If V8 decides it's time to GC an object, it does usually because it can't reach it in the object graph. I haven't seen cases where the pure js object is being collected early, thus causing errors. This happens only for js objects that have native counterparts like var nativeButtonInstance = new android.widget.Button() because, in the ideal scenario, the runtime needs to take care of their garbage collection.

[yyankov]

I am getting a similar error on random occasions.

Setup:

"dependencies": {
"nativescript": "^3.4.0",
"nativescript-angular": "^5.0.0",
"nativescript-drop-down": "^3.2.0",
"nativescript-local-notifications": "^2.0.2",
"nativescript-plugin-firebase": "^5.0.5",
"nativescript-pro-ui": "^3.2.0",
"nativescript-theme-core": "~1.0.2",
"nativescript-toast": "^1.4.6",
"reflect-metadata": "~0.1.8",
"rxjs": "^5.5.6",
"tns-core-modules": "^3.4.0",
"zone.js": "^0.8.18"
},
"devDependencies": {
"babel-traverse": "^6.26.0",
"babel-types": "^6.26.0",
"babylon": "^6.18.0",
"lazy": "^1.0.11",
"nativescript-dev-typescript": "^0.6.0",
"typescript": "^2.6.2"
}

Error:

com.tns.NativeScriptException: Attempt to use cleared object reference id=2263
at com.tns.Runtime.getJavaObjectByID(runtime.java:897)
at com.tns.Runtime.callJSMethodNative(Native Method)
at com.tns.Runtime.dispatchCallJSMethodNative(runtime.java:1088)
at com.tns.Runtime.callJSMethodImpl(runtime.java:970)
at com.tns.Runtime.callJSMethod(runtime.java:957)
at com.tns.Runtime.callJSMethod(runtime.java:941)
at com.tns.Runtime.callJSMethod(runtime.java:933)
at com.tns.gen.com.telerik.widget.list.ListViewAdapter_frnal_ts_helpers_l58_c38__ListViewAdapter.onCreateViewHolder(com.telerik.widget.list.listviewadapter.java)
at com.telerik.widget.list.ListViewWrapperAdapter.onCreateViewHolder(listviewwrapperadapter.java:459)
at com.telerik.widget.list.ListViewWrapperAdapter.onCreateViewHolder(listviewwrapperadapter.java:20)
...
at org.nativescript.widgets.CommonLayoutParams.measureChild(commonlayoutparams.java:262)
at org.nativescript.widgets.MeasureHelper.measureChildFixedColumnsAndRows(gridlayout.java:1055)
at org.nativescript.widgets.MeasureHelper.measure(gridlayout.java:865)
at org.nativescript.widgets.GridLayout.onMeasure(gridlayout.java:279)
at android.view.View.measure(view.java:21121)
at org.nativescript.widgets.CommonLayoutParams.measureChild(commonlayoutparams.java:262)
at org.nativescript.widgets.ContentLayout.onMeasure(contentlayout.java:32)

[Plamen5kov]

Hi @yyankov thank you for your feedback.
As I previously explained this error is caused by the fact your business logic encloses a native object, that's already collected. To put it more simply, you need to find the js object that's cleared and persist it in javascript in some of the ways I mentioned previously.

When I look at the error you posted, I can point you in the right direction: ListViewAdapter.onCreate it's probably an object enclosed by this function, which has a javascript counterpart.

[Plamen5kov]

Closing due to lack of activity.

[daveware-nv]

@NathanaelA
It is also (most likely) due to "markingMode": "none", which is not really a supported feature. So I would say whether or not this should be left open should be related to what the future plans are regarding "markingMode": "none"

[Plamen5kov]

@NathanaelA
Just because markingmode:"none" causes it to happen more often doesn't mean that the normal GC doesn't cause it to happen in other timing.

That's incorrect. When marking mode is set, it changes the way GC works, so any related GC issues will be completely different.

---

And by the way, is in the onCreateViewHolder of the ListViewWrapperAdapter, and that actually is in the Nativescript-Pro-UI --- not his code... So in this case the error is 100% a Telerik/Progress issue; not something he can easily fix...

It's really unfortunate that you found the problem in nativescript-pro-ui, if that's really where the problem resides, but we haven't planned to make the plugins compatible with markingMode: "none", at least not yet since it's only an experimental feature, and it should be respected as such as @daveware-nv already mentioned.

---

In addition since markingmode:none hasn't been depreciated (but still in consideration(?) for a solid release); then this bug has should at a minimum stay open until it is fixed or markingmode:none is removed from the engine.

I closed the issue, just as I said "because of the lack in activity". We'd be happy to reopen it, should the need occur. For now it hasn't, because there's no new development on our side, nor on the current issue.

---

@NathanaelA If you figured out, something we haven't please share your knowledge or better yet do a PR, as you're knowledgeable enough to provide assistance to the plugin authors.

[etabakov]

I'm reopening the issue as the problem is real and is not resolved. Our plans for after the 4.0 release are to focus on making plugins maintained by NativeScript compatible with markingMode: none. Cases like this one will be useful for us to validate whether we have covered all cases.

[gsmedley]

Now that it's post 4.0, it would be really great news if you were working on the markingMode changes for the plug-ins. NS is an excellent system, well designed and with a great developer experience. Unfortunately the current choice between slowness (markingMode not set) and crashes (markingMode set to none) makes it difficult to ship on Android.

[etabakov]

Indeed, this is one of the things we will focus on for 4.1.

[pana-cc]

Hi everybody,
@gsmedley @etabakov @NathanaelA

There is a class of "Attempt to use cleared object reference" errors that is thrown out there, here is some insight on the design of markingMode: "none".

1. JavaScript instances as long as they are alive (e. g. can not be GCed) will keep strong references to the Java instances.
2. When JavaScript instance becomes eligible for collection, it will change the strong reference to a weak reference to the Java instance. From that point on the JavaScript instance will be "revived" as long as the Java instance is not collected.
3. Only after the Java instance is collected, the JavaScript instance will be let to be collected.

This means that when markingMode: "none" is enabled the JavaScript instances will always live longer than the Java instances. Also as long as something holds the JavaScript instances alive (on stack, on global, on the module exports, or a function that is exported captures stuff in its closure etc.) the Java instances will survive.

So any error that happen, related with the Java instance being prematurely collected, should be due to JavaScript trying to call to Java. For example if you call method on an object, and that object was already collected, you should get a JavaScript callstack, and fixing errors having this callstack should be easy.
The error should be similar to the following screenshot:

So once you get that, you as developer should pretty much figure out of the JavaScript callstack which instance was collected too early, go up the stuck (as much as possible) and retain somehow any listeners, or java objects that doesn't seem to have their JavaScript instances retained long enough. (we need proper article on this one)

On the other hand the error report for failed methods seem fine (you have JavaScript stack) but the:

#0. Crashed: main: 0 0 0x0000000000000000
       at .Error: com.tns.NativeScriptException: Attempt to use cleared object reference id=48048(com.tns.NativeScriptException: Attempt to use cleared object reference id=48048
    com.tns.Runtime.getJavaObjectByID(Runtime.java:893)

kind of errors are total no-go.

The {N} Android team should probably figure out where these Attempt to use cleared object reference are thrown:
https://github.com/NativeScript/android-runtime/blob/f88bfe069fd07a7ae561978ab4d97737cfc01603/test-app/runtime/src/main/java/com/tns/Runtime.java#L897

Figure out this getJavaObjectByID is only used from C++:
https://github.com/NativeScript/android-runtime/blob/7897e2dc5a4b0a819ce1ce549bb86d6d6e2c40e3/test-app/runtime/src/main/cpp/ObjectManager.cpp#L30

And that's why the Java callstack above seems lacking enough information.
Following the "used by" chain you end up in NewWeakGlobalRefCallback then in:

https://github.com/NativeScript/android-runtime/blob/7897e2dc5a4b0a819ce1ce549bb86d6d6e2c40e3/test-app/runtime/src/main/cpp/ObjectManager.cpp#L25

The cache is initialized with this, and this cache on the other hand is used only in the ObjectManager GetJavaObjectByID:

https://github.com/NativeScript/android-runtime/blob/7897e2dc5a4b0a819ce1ce549bb86d6d6e2c40e3/test-app/runtime/src/main/cpp/ObjectManager.cpp#L134

Which is then used by GetJavaObjectByJsObject:
https://github.com/NativeScript/android-runtime/blob/7897e2dc5a4b0a819ce1ce549bb86d6d6e2c40e3/test-app/runtime/src/main/cpp/ObjectManager.cpp#L79

GetJavaObjectByJsObject is called on places where the runtime is marshalling arguments for transition from JavaScript to Java. The errors for figuring out the "this" in a method call is well handled (like the screenshot above) but then, GetJavaObjectByJsObject is also used in:

https://github.com/NativeScript/android-runtime/search?q=GetJavaObjectByJsObject&type=Code

• FieldAccessor.cpp
• ArrayBufferHelper.cpp
• ArrayElementAccessor.cpp
• JsArgConverter.cpp
• etc.

Every single place where it is used, we have isolate that is available and a JavaScript callstack should be available somewhere there, but the generated NativeScriptException seems to hide it.

With that said (if you choose to proceed with markingMode: none), the android runtime will have to do some advancements in the error reporting here. Since the errors will be random and hard to reproduce the error messages should be enough to locate and fix potential problems. These errors should be collectible by error reporting services (android crash reports? firebase?). Only when this is done we will be able to provide the "how to fix".

[pana-cc]

The full log has javascript traces:
StackLayout.ViewBase._addViewCore (<embedded>:57782:18)
at Label.ViewBase._setupUI (<embedded>:57858:49)(com.tns.NativeScriptException: Attempt to use cleared object reference id=48048
at ViewUtil.insertToLayout (<embedded>:54934:20)(com.tns.NativeScriptException: Attempt to use cleared object reference id=48048

[sasa-cj-jovanovic]

Sorry for the delay I was absent for a few weeks.

I have an update how the issue was solved on my end. I upgraded native script/angular/ts to the latest ones as describe in here: https://docs.nativescript.org/releases/upgrade-instructions and the issue was magically solved.

Now instead of app breaking and "attempt to use cleared object reference" exceptions I am receiving different exceptions very benign ones: JS: Error in downloadBitmap - java.io.InterruptedIOException: thread interrupted

[dodongphure]

I has the same error message:

Error in downloadBitmap - java.io.InterruptedIOException: thread interrupted

My package.json:
"nativescript-angular": "^7.2.1",
"tns-core-modules": "^5.2.0"

My app has a List which contains posts, post will have image. So when scroll down and up quickly, this error will show.
I did some searching and see that it may relate to http requests in java code. Here's one the results I found: square/retrofit#844. Not sure relate to this or not.

[vtrifonov]

You can try with android@next if you can easily reproduce the error to see whether the pull request above fixes it.

[valera1401]

Old issue. I though that the issue has gone after moving to NS 5.3. But it just occurs less oftеn.
Error occurs after some time if style changes dynamically based on condition (for example [class.selected]="someBooleanVariable")

Unhandled Promise rejection: com.tns.NativeScriptException: Attempt to use cleared object reference id=1511
com.tns.Runtime.getJavaObjectByID(Runtime.java:1006)
com.tns.Runtime.callJSMethodNative(Native Method)
com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1203)
com.tns.Runtime.callJSMethodImpl(Runtime.java:1083)
com.tns.Runtime.callJSMethod(Runtime.java:1070)
com.tns.Runtime.callJSMethod(Runtime.java:1050)
com.tns.Runtime.callJSMethod(Runtime.java:1042)
com.tns.gen.java.lang.Runnable.run(Runnable.java:17)
android.os.Handler.handleCallback(Handler.java:790)
android.os.Handler.dispatchMessage(Handler.java:99)
android.os.Looper.loop(Looper.java:164)
android.app.ActivityThread.main(ActivityThread.java:6494)
java.lang.reflect.Method.invoke(Native Method)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) ; Zone: ; Task: Promise.then ; Value: Error: com.tns.NativeScriptException: Attempt to use cleared object reference id=1511
com.tns.Runtime.getJavaObjectByID(Runtime.java:1006)
com.tns.Runtime.callJSMethodNative(Native Method)
com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1203)
com.tns.Runtime.callJSMethodImpl(Runtime.java:1083)
com.tns.Runtime.callJSMethod(Runtime.java:1070)
com.tns.Runtime.callJSMethod(Runtime.java:1050)
com.tns.Runtime.callJSMethod(Runtime.java:1042)
com.tns.gen.java.lang.Runnable.run(Runnable.java:17)
android.os.Handler.handleCallback(Handler.java:790)
android.os.Handler.dispatchMessage(Handler.java:99)
android.os.Looper.loop(Looper.java:164)
android.app.ActivityThread.main(ActivityThread.java:6494)
java.lang.reflect.Method.invoke(Native Method)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807) Error: com.tns.NativeScriptException: Attempt to use cleared object reference id=1511
com.tns.Runtime.getJavaObjectByID(Runtime.java:1006)
com.tns.Runtime.callJSMethodNative(Native Method)
com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1203)
com.tns.Runtime.callJSMethodImpl(Runtime.java:1083)
com.tns.Runtime.callJSMethod(Runtime.java:1070)
com.tns.Runtime.callJSMethod(Runtime.java:1050)
com.tns.Runtime.callJSMethod(Runtime.java:1042)
com.tns.gen.java.lang.Runnable.run(Runnable.java:17)
android.os.Handler.handleCallback(Handler.java:790)
android.os.Handler.dispatchMessage(Handler.java:99)
android.os.Looper.loop(Looper.java:164)
android.app.ActivityThread.main(ActivityThread.java:6494)
java.lang.reflect.Method.invoke(Native Method)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)
at Object.onBackgroundOrBorderPropertyChanged (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\styling\background.android.js:67:51)
at GridLayout.View._redrawNativeBackground (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\view\view.android.js:674:30)
at GridLayout.View. (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\view\view.android.js:654:15)
at applyPendingNativeSetters (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\properties\properties.js:939:29)
at Object.initNativeView (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\properties\properties.js:901:10)
at GridLayout.ViewBase.onResumeNativeUpdates (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\view-base\view-base.js:626:23)
at GridLayout.ViewBase._resumeNativeUpdates (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\view-base\view-base.js:272:19)
at GridLayout.ViewBase._batchUpdate (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\view-base\view-base.js:281:19)
at CssState.updateDynamicState (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\styling\style-scope.js:344:20)
at CssState.onChange (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\styling\style-scope.js:312:19)
at GridLayout.ViewBase._onCssStateChange (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\view-base\view-base.js:643:25)
at valueChanged (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\view-base\view-base.js:762:15)
at GridLayout.Property.set [as className] (E:\Work\Projects\Couriers\MobileApp\node_modules\tns-core-modules\ui\core\properties\properties.js:107:26)
at ViewUtil.syncClasses (E:\Work\Projects\Couriers\MobileApp\node_modules\nativescript-angular\view-util.js:323:25)
at ViewUtil.removeClass (E:\Work\Projects\Couriers\MobileApp\node_modules\nativescript-angular\view-util.js:312:15)

[jpierront]

@valera1401 It should be fixed in 5.4, so for now use android@next

[valera1401]

@jpierront I already use android@next
"tns-android": {
"version": "5.4.0-2019-05-02-235338-05"
}

[valera1401]

@jpierront Please notice that before NS 5.3 this exception occurred after short period of time after the app launch (2-3 minutes). Now it occurs after longer period, maybe after 15 minutes of the app working.

[pana-cc]

The table will not become too large as it has to keep trace of what is the JavaScript class and where it is declared for a Java instance. So when the JS instance is collected you have to write up in the table debug information for the Java instance. That information can be stored in weak dictionary for example that will be cleared when the Java instance is collected.

[pana-cc]

When Java is calling a method and a reference is passed that... the Java instance has been collected? That throws null reference exception, right? It will not try to marshal it to its JavaScript instance. But I agree that we need very good error reporting. When these errors occurs we often have the Java instance and can provide information from it as well as full stack trace sandwich and if possible the JS class source...

[n0mer]

@NathanaelA gentle reminder, in case you've had a chance to look at this.

[gkoulin]

@NathanaelA I would also love to see this resolved since NS is so awesome!

[ivandejesus]

@NathanaelA error still exists.

[jpierront]

@ivandejesus See NativeScript/NativeScript#7867 for a possibly working hack if you are in this case :)

[kokosky93]

I am facing this issue too..

[ematechno]

I'm facing the same issue too - any news on fix or workaround?

[kokosky93]

I had to remove marking Mode: None and until I did this I haven't seen this exception. Someone mentioned about plugins which don't support marking mode: none.

[ematechno]

I fear the issue is NOT related to Plug-in only.
Did you have significant performance issue, removing marking Mode?

[kokosky93]

In generall apllication performance is pooor even though application is really simple. I didn't notice difference with and without marking mode. This is Angular based one.

[gkoulin]

I've given up on nativescript and tamers to flutter. It seems to be gaining speed and has plenty of useful plugins. Plus it comes with a lot more features out of the box. On 26 Jan 2020 16:46, kokosky93 <notifications@github.com> wrote:In generall apllication performance is pooor even though application is really simple. I didn't notice difference with and without marking mode. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[ematechno]

I'm evaluating FLUTTER too, I agree it looks very promising - furthermore, now NS Plugins require subscription :(

[gkoulin]

I've fairly new to mobile development. And at first nativescript has been pretty great. Use of html and css can be both a benefit and a hindrance. But when this crash has started reoccurring as the client data increased, it was a no go (still fairly modest collection). I had to ditch nativescript after this bug ticket had been open for such a long time. After all this goes back a couple of years or so. On 27 Jan 2020 03:25, Nathanael Anderson <notifications@github.com> wrote:@gkoulin @ematechno - Just a FYI; I have actually done some Flutter apps (after all I am a contractor -- I do work in almost every language if you pay me. 😀 ) You have a lot of serious & signifincant gotchas/bugs with it. I honestly would not put any client apps in most areas I do apps on Flutter at this point. There are a couple areas that Flutter would be great for, but the majority; you are just wasting your time, as your clients will be ticked at your delivered frequently crashing app... Forewarned is forearmed. It has wonderfully awesome tooling, and I love the developer experience with Flutter; but the apps it creates, you will run into weird compatibility issues in several areas than with NativeScript/ReactNaitve or even just plain Native. Awesome concept; lousy compatibility and some of these significant bugs reports have been open forever. :( As for ProPlugins -- you are correct, I started the subscription service -- it, imho, was the only way to guarantee high quality plugins would continue on NativeScript. Too many open source authors were facing burn out and no one was picking up the pieces. I know for myself, I would have stopped maintaining most my plugins as the costs to my family were too high. But ProPlugins actually helps financially support some of the time spent on the plugins, and as such it has allowed me to do probably 30+ updates across all my plugins without the cost to my family being horrible. The crazy thing is, no one thinks about how much they are getting paid per hour to make an application, but they complain about what costs them probably only 1-5 hours of their time per year, if their company can afford to pay them 30k - 100k, The subscription is crazy cheap for all the development work that they don't have to do now... 😀 —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[lostation]

Great... !!! I also encountered this kind of bug using one image inside each item of a RADListView while scrolling fast up or down... Is there a way of handling image differently to avoid this kind of error ? Or just don't use RadListView anymore ? Thanks for help.

[NickIliev]

@lostation provide a demo application that reproduces the issue so we could investigate further. Simply using a RadListView with a lot of images is not reproducing the issue on my side - are you sure you are not using other elements/layouts/plugins inside the item templates?

[lostation]

Hi, Thanks for your reply. No unfortunately, I’m not authorized to put a demo example. But really it’s nothing fancy at all… it’s a regular RadListView as described into Nativescript docs for Angular. I’ve just added a <Image> tag into the list item into a GridLayout, there’s no external plugin or whatever. If I remove the image it works just fine…so it’s clearly linked to a nullable element at mobile platform side. If I turn markingMode to full it also not crash anymore…but indeed poor performance after some times. I’ve also tried using a simple ListView component (not radlist)… but it’s the same scroll behavior behind…If a scroll too fast..then randomly it will crash the app. BUT,… If a put a simple Gridlayout as a wrapper around the Image tag with a *ngIf directive to verify if src can be fulfilled it seems to not crash anymore. So If no src data … no Image element into the template and no link to android glide or Picasso adapter or something. I will continue with that fix…and let you know If I get other JNI crash from android. Thanks anyway. Lo.

…

Le 17 févr. 2020 à 10:39, Nick Iliev ***@***.***> a écrit : @lostation <https://github.com/lostation> provide a demo application that reproduces the issue so we could investigate further. Simply using a RadListView with a lot of images is not reproducing the issue on my side - are you sure you are not using other elements/layouts/plugins inside the item templates? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#887>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACX5G6WUZJN5DTPV5HX4WE3RDJLMZANCNFSM4EFXU3VA>.