Replies: 3 comments 9 replies
-
That sounds technically right. I honestly never faced this situation, and I think the root cause is I've recently pushed a change so that the Frida thread gets detached from IL2CPP only when the script is about to get unloaded; this will allow the IL2CPP internals to be accessible within the Frida REPL or inside However, I'm not sure if this change really helps you (imagine this scenario: your thread creates the string, you pass the string somewhere, you reload the script or exit Frida, the gc frees the string). Perhaps I can add a parameter to Alternatively, you could create the string from the main thread instead: Il2Cpp.perform(async () => {
const string = await Il2Cpp.mainThread.schedule(() => Il2Cpp.string("hello"));
}); However, notice the synchronization context of a thread (this is what |
Beta Was this translation helpful? Give feedback.
-
I honestly don't know if there's a way to keep an object always alive, despite the thread who created it exits or gets detached. |
Beta Was this translation helpful? Give feedback.
-
After a quick read at the documentation, the object won't be collected as long as you create a strong reference to it (pinning is not necessary), regardless of the thread who created it. If you want that string to be always alive (aka leak it), don't free the handle. https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.gchandle |
Beta Was this translation helpful? Give feedback.
-
Everytime I create a C# String it gets garbage collected after a while. I am pinning the object so that it does not get GC'ed but I don't know if I really need to free the handle when the script is unloaded like this:
Beta Was this translation helpful? Give feedback.
All reactions