fix: memory leaks & WeakRefs

[rigor789]

WIP

[brysem]

Would it be possible to get a RC release for testing?

[rigor789]

It's the strdup change, it's excluded from the alpha build, just haven't found a good solution for it's leak yet...

[rigor789]

So the alpha has all these changes except the strdup change, I assume you are talking about this strdup change?
0f96dc4#diff-bec6e3d6b4fa0eacfb7726d6e5915c9eecda4e319bc61f71a0527e740eb197ddR160

Yeah, that strdup needs to be present (or something that makes a copy of the data, as once it leaves the scope it looks like the value is freed).

That one is a tricky one - the data in some cases does persist fine without the strdup call, and is released once no longer needed, but sometimes that data is released too early. Having that strdup there does leak all the memory though, since it's never released afterwards. This is a big issue for apps that rely heavily on SQLite, since as far as I understand - all the queries are going through that exact branch - for most apps, it's probably not a huge deal if it only leaks a few times (still bad, but tolerable).

But yes, the latest alpha has that one change reverted before build - because it does cause the failure you are seeing in some cases (garbage passed instead of the right value, because it's freed too early).

@darind suggested we try making the arguments into Persistent values and then add them to a global cache where we can get notified when the argument is eligible for releasing, but I couldn't test that yet (won't be able to for the next 2 weeks).

The fastest way to debug/step through and reach that branch is to call

NSMethodSignature.signatureWithObjCTypes('v@:c');

if you want to experiment with that idea.

---

WeakRefs seem to take a LOT longer to be collected

v8's WeakRefs make no guarantees when they are actually released or GC'd - with this PR, we are switching to the built-in WeakRef implementation, so that change is expected...

[brysem]

If you would like you can also try this version (a version I built for a different nStudio client)

Thanks. I will give it a try today.

As already mentioned by Igor the change on 0f96dc4#diff-bec6e3d6b4fa0eacfb7726d6e5915c9eecda4e319bc61f71a0527e740eb197ddR160 does indeed create a lot of weird issues for the nativescript-sqlite package. It also broke something in frame transitions from the core (if my memory serves me right).

[cla-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign the CLA at https://www.nativescript.org/cla.
CLA has not been signed by users: @darind, @brysem, @Logikgate.
After signing the CLA, you can ask me to recheck this PR by posting @cla-bot check as a comment to the PR.