"global reference table overflow" exception with very large numbers of "mono.java.lang.RunnableImplementor" #15769
-
|
Hello everyone, I've had a crash in a MAUI application of mine with the following message: I've created this as a discussion and I don't know whether this is my fault or an issue with MAUI. If anybody has any ideas of how I could investigate this further I'd love to hear them. I also have a complete copy of the debug output from Visual Studio. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 6 replies
-
|
So the solution to this ended up being: be careful when using Android.View.Post(Action) when there's a chance that the view might not be attached to a window. This method will create a RunnableImplementor and call Post(IRunnable) with it. RunnableImplementor's constructor adds it to a dictionary to keep a hold of the reference, which it is then removed from at the end of the Run implementation. Problems arise when Run isn't called, such as when the View is detached from a Window and then destroyed, as the RunnableImplementor will sit there taking up memory and JNI handles forever, and presumably preserving references to whatever is used within the Action as well. Normally it would be cleaned with the View's mRunQueue, but the presence of the C#-side dictionary causes it to persist in this scenario. |
Beta Was this translation helpful? Give feedback.
-
|
@sjordanGSS does We are wondering if the code in xamarin/xamarin-android should be something like: public bool Post (Action action)
{
var runnable = new Java.Lang.Thread.RunnableImplementor (action, true);
bool value = Post (runnable);
if (!value) runnable.Dispose();
return value;
} |
Beta Was this translation helpful? Give feedback.
-
|
It's been a while since I had a proper look at this, but from memory it still returns true when things go wrong. |
Beta Was this translation helpful? Give feedback.
-
|
@sjordanGSS so can you omit the It does seem like this is problematic: // RunnableImplementor object lives forever
// Anything captured in the lambda might also live forever
new View(context).Post(() => ...);But, in what case do you need to write code like this? |
Beta Was this translation helpful? Give feedback.
-
|
I found this when using a var timer = new System.Threading.Timer(() =>
{
// timer invokes outside of the UI thread
view.Post(() =>
{
// this gets us onto the UI thread, so we can change the view's properties safely
}
});My solution in the end was to instantiate my own |
Beta Was this translation helpful? Give feedback.
-
|
Can you file an issue that describes the problem more like:
If there is some usage of |
Beta Was this translation helpful? Give feedback.
-
|
I have a very similar issue [0:] Navigating to Web Media #: https://fast.com/ |
Beta Was this translation helpful? Give feedback.
So the solution to this ended up being: be careful when using Android.View.Post(Action) when there's a chance that the view might not be attached to a window. This method will create a RunnableImplementor and call Post(IRunnable) with it. RunnableImplementor's constructor adds it to a dictionary to keep a hold of the reference, which it is then removed from at the end of the Run implementation. Problems arise when Run isn't called, such as when the View is detached from a Window and then destroyed, as the RunnableImplementor will sit there taking up memory and JNI handles forever, and presumably preserving references to whatever is used within the Action as well. Normally it would be clea…