Repository navigation
[Marking Mode: None]: Crash: Attempt to use cleared object reference #887
Description
Activity
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.jsonso 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 markingmode=nonedoesn't check which js objects have a native counterpart and should survive GC and which don't.- changed the title
[-]Crash: Attempt to use cleared object reference [/-][+][Marking Mode: None]: Crash: Attempt to use cleared object reference [/+]on Nov 29, 2017 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-couchbasewe're using a custom version derived from1.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: noneis the 3.2 announcement blog post and it wasn't detailed enough on what is required to preventmarkingMode: nonecausing 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.
...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 classandroid.native.NCallback: native interface
The
implementoris enclosed by thecallbackimplementation, but withmarkingMode: noneenabled we no longer take care of finding that connection out. So when GC happensimplementorinstance 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. (implementoris attached toglobalis 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.
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.
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-uisince it does not have source available. Andnativescript-angularsince my app is an angular one this will be used heavily by every screen (and a quick look though the stacktrace I posted above revealsEmulatedRenderer.NativeScriptRenderer.insertBefore, which I believe corresponds to this line https://github.com/NativeScript/nativescript-angular/blob/42e438ce4b206ff96fb2fe31e9968fcfc555f5a6/nativescript-angular/renderer.ts#L101)Unfortunately
markingMode: nonemakes 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.Reacted by Plamen Petkov and appsea@daveware-nv, did you manage to fix your issue or are you still trying to figure out where the problem is?
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-angularandnativescript-pro-ui, which I wouldn't know where to start looking, do you know if these have been vetted similar totns-core-modules?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: noneat 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.
Both plugins are usable with the current version of the android runtime, but they are not compatible with
markingMode: noneat 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: noneisn'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 supportingmarkingMode: nonefor 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?
Do you know what the timeframe (if any) for supporting markingMode: none for those plugins is?
We've not settled on using
markingMode:noneby 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.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.onCreateit's probably an object enclosed by this function, which has a javascript counterpart.Reacted by Manav KothariClosing due to lack of activity.
36 remaining items
@NathanaelA error still exists.
@ivandejesus See NativeScript/NativeScript#7867 for a possibly working hack if you are in this case :)
Reacted by ivandejesusI am facing this issue too..
I'm facing the same issue too - any news on fix or workaround?
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.
I fear the issue is NOT related to Plug-in only.
Did you have significant performance issue, removing marking Mode?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.
- 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.
I'm evaluating FLUTTER too, I agree it looks very promising - furthermore, now NS Plugins require subscription :(
- 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.
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.
@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?
- 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>.Reacted by Nikolay Iliev, Andrew Shortall, Houssam Mehdi and FranciZ
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:
Built using webpack (
npm run ns-bundle --android --build-app --snapshot --clean --release)Also using in
app/package.json: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.
full trace at https://pastebin.com/JEGTYrpx
Please tell us how to recreate the issue in as much detail as possible.
Unknown. Possibly random.