You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you know, the proxy sets itself as the UIScrollViewDelegate:
scrollView.delegate =self
For our use case, the scrollView is a UITableView; so the delegate is a UITableViewDelegate.
As a result, it will be sent messages like tableView:viewForHeaderInSection:.
The framework does consider this, as we see in the following code to forward on other messages:
In ARC in Swift: Basics and Beyond, we see how Swift is non-lexical. Above, in forwardingTarget(for:), originalDelegate may respond to a selector and be deallocated when it is returned (because it is weak)
originalDelegate may cause responds(to:) to return true, but have been deallocated in forwardingTarget(for:)
The second is why we are seeing crashes in our app.
Just before the crash, forwardingTarget(for:) is called with selector tableView:viewForHeaderInSection: and the originalDelegate is nil.
Returning nil for this scenario in forwardingTarget(for:) does not stop the invocation.
So we are experiencing the following crash in our app:
'NSInvalidArgumentException', reason: '-[OverlayContainer.OverlayScrollViewDelegateProxy tableView:viewForHeaderInSection:]: unrecognized selector sent to instance'
It looks to me like you might have done the same as this SO answer.
Currently, I don't think it's a correct implementation of a proxy in Swift for weak references.
The text was updated successfully, but these errors were encountered:
bshuttkg
changed the title
NSInvalidArgumentException Unrecognized Selector Crash Due To OverlayScrollViewDelegateProxy Deallocation Issue
NSInvalidArgumentException unrecognized selector crash due to OverlayScrollViewDelegateProxy deallocation issue
Jan 20, 2025
Hey @gaetanzanella, thank you for getting back to me 🙏 .
Currently, I'm not sure that there is a Swift solution for the selector proxy pattern we are attempting here.
This might be an Objective-C thing, but I would like to be wrong about that.
I've tried returning nil in forwardingTarget(for:) when the originalDelegate is deallocated, but the invocation seems to be invoked anyway.
If Objective-C was an option (probably not) then:
This blog discusses how this might be achieved using NSObject
Describe the bug
Memory deallocation issue in the
OverlayScrollViewDelegateProxy
.Environnement
Description
As you know, the proxy sets itself as the
UIScrollViewDelegate
:For our use case, the
scrollView
is aUITableView
; so thedelegate
is aUITableViewDelegate
.As a result, it will be sent messages like
tableView:viewForHeaderInSection:
.The framework does consider this, as we see in the following code to forward on other messages:
where:
But there is a bug here, a few:
forwardingTarget(for:)
,originalDelegate
may respond to a selector and be deallocated when it is returned (because it isweak
)originalDelegate
may causeresponds(to:)
to returntrue
, but have been deallocated inforwardingTarget(for:)
The second is why we are seeing crashes in our app.
Just before the crash,
forwardingTarget(for:)
is called with selectortableView:viewForHeaderInSection:
and theoriginalDelegate
isnil
.Returning
nil
for this scenario inforwardingTarget(for:)
does not stop the invocation.So we are experiencing the following crash in our app:
It looks to me like you might have done the same as this SO answer.
Currently, I don't think it's a correct implementation of a proxy in Swift for weak references.
The text was updated successfully, but these errors were encountered: