Ensure thread safe access to UIViewController
associated properties
#153
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
This PR addresses a potential crash caused by threading issues when accessing or modifying
UIViewController
properties using Objective-C runtime associations (objc_setAssociatedObject
andobjc_getAssociatedObject
) on a background thread.An example: when a
UIViewController
with a very short lifespan (like we observe on, for exampleSwiftUI.UIKitNavigationController
) is being deallocated, we could be adding associated objects at the same time, leading to unsafe interactions with the Objective-C runtime.To prevent this, the code has been updated to ensure all accesses to
vc.emb_identifier
(a property backed byobjc_setAssociatedObject
) are performed on the main thread, ensuring theUIViewController
is in the rendering process and not being deallocated.Extra
Found out that
LengthOfNameValidator
was preventing to push some.viewLoad
/.view
spans due to name length. We've added a whitelist to prevent this from happening.