[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.