[iOS][net6] Tried to create a managed reference from an object that already has a managed reference #8688
Comments
jeromelaban
added
kind/bug
|
I've seen similar messages in macOS legacy (pre-net6) |
|
This is printed when the runtime finds out there's two managed instances for a single native one. This should have a very limited performance impact (unless it happens a lot) since managed instances are generally lightweight (versus the native instance). This situation can happen (it's actually needed) with Xamarin SDK bindings, most are stateless bindings (wrappers) and different rules (like recreating managed peers on demand) are possible for such bindings, including not printing this warning. Now "user types" can have extra state/logic in managed code so having more than one managed instance associated to a native one can lead to weird situations at runtime. The warning is kind new'ish (a year old) and was introduced with coreclr support (even if it's printed for mono too) Before that PR it only existed in special (local) builds to debug refcounting IOW the condition(s) leading to this warning being printed likely existed inside Uno for a long time. I'll try to identify the Uno code that triggers this... |
|
I'm wondering if this could be related to this portion: where we are handling memory management explicitly to avoid objects lingering too much in memory. This is used avoid UIKit to re-create managed wrappers when children have lost their managed parent counter part, but UIKit still invokes overriden methods.
|
|
Quite likely related! I have this generated code in my call stack before this is printed. |
|
That is interesting, this would mean we're rematerializing objects that were already collected. GC is hard :) |
|
yes The good news is that this likely means there not much chance this could break things. I'm updating/rebuilding xamarin-macios to see the order of disposal... |
|
🧠 dump I disabled a few things that could have interfered but that did not help. Also made a small test case, using only XI, does not hit the same condition. More investigation will be needed. Also replacing |
|
This is a Xamarin runtime issue where calling Filed as xamarin/xamarin-macios#15089 |
|
can issue #8682 be related to this issue? |
@workgroupengineering it could be. The crash is different and many things can lead to such crash. However the (azure) logs shows there was a problem with the same code just before the crash. That makes it a good suspect but there's likely something else too involved (like a call to a disposed instance). |
|
This one is likely to be related to a collected instance indeed. It's not yet clear why though. |
|
As suspected the condition to trigger the bug differs a bit on iOS. In that case the
#elif XAMARIN_IOS
SetNeedsLayout();
SetLayoutFlags(LayoutFlag.MeasureDirty);
#elif __MACOS__
base.NeedsLayout = true;
SetLayoutFlags(LayoutFlag.MeasureDirty);
#endifThe call to the disposed-then-reregistered instance is showing the warning. Sadly a variation of the macOS workaround cannot be applied here. Call StackThe call stack is much deeper. It seems measurements are being made between the first/original
There's probably some performance gains in avoiding those computations when an object is going thru disposal. In addition such optimization would avoid the calls to |
|
Very interesting find! Thanks! So we could either determine that the object in disposed state somehow to avoid this entire tree, or find a way to determine if the superview is already collected. Is there a way to do that without re-creating the managed counterpart ? |
There's a That could be used to skip the measuring code when Since that would be located (and set) inside
The flags are not exposed publicly by Xamarin SDKs. It would require reflection (quite slow) or some unsafe code that assume the current memory layout of Ideally Microsoft will fix this 🤞, e.g. get notified if the instance is re-registered, and this won't be an issue in the future. There's a third option: That Uno For net6-macos, which uses CoreCLR, it might also be counter productive to run this code. It might be a good idea to measure again it's impact and, if possible, simplify or even remove it. I'll start with the first option to see how self-contained the fix would be... |
|
So we cannot just avoid the condition - it has other merits but it does not workaround the resurfacing issue (since the order of disposal is not under our control). What seems to be working is using Since the state was corrected the call to I'll clean my code and split this into 2 or 3 consecutive PRs. That will make it easier to revert the hack'ish (above) part while keeping the other improvements. |
…ss common - avoid generating disable `Dispose` code for Android - inline `RequestCollect` method (if only to reduce metadata) - reuse the `Count` check to avoid the enumerator (iOS) - use the macOS r/w `Subviews` property to avoid multiple native calls
…ss common - avoid generating disable `Dispose` code for Android - inline `RequestCollect` method (if only to reduce metadata) - reuse the `Count` check to avoid the enumerator (iOS) - use the macOS r/w `Subviews` property to avoid multiple native calls
…ss common - avoid generating disable `Dispose` code for Android - inline `RequestCollect` method (if only to reduce metadata) - reuse the `Count` check to avoid the enumerator (iOS) - use the macOS r/w `Subviews` property to avoid multiple native calls
…ss common - avoid generating disable `Dispose` code for Android - inline `RequestCollect` method (if only to reduce metadata) - reuse the `Count` check to avoid the enumerator (iOS) - use the macOS r/w `Subviews` property to avoid multiple native calls
refactor: Tweak generated `Dispose(bool)` to make #8688 less common
|
Noticed this warning is showing up all the time when running iOS runtime tests - probably should be checked to see if it is a regression or not |
|
@cconner is seeing this, so would be good to see if this is a regression |
|
This is not a regression, this message is not having any incidence on the app behavior. |
Current behavior
Run an net6.0-ios app (e.g. Uno.Gallery) and you notice error messages like this one:
Expected behavior
No error messages.
How to reproduce it (as minimally and precisely as possible)
No response
Workaround
None.
Works on UWP/WinUI
No response
Environment
Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia
NuGet package version(s)
4.2.6
Affected platforms
iOS
IDE
No response
IDE version
No response
Relevant plugins
No response
Anything else we need to know?
No response
The text was updated successfully, but these errors were encountered: