Skip to content

Conversation

hamidmalek
Copy link

These changes fix the issue regarding inconsistence type inference in iOS. The original error is as follows:

*** First throw call stack:
(0x193fff21c 0x191499abc 0x194069614 0x193f13a1c 0x193f13aa0 0x10b6c6c8c 0x10b6bda98 0x10b6c0538 0x1bd7cad94 0x1bd7caec4 0x1bd7c7a18 0x1bd786a40 0x1bd78422c 0x1bd784114 0x100d90584 0x100daa064 0x100d9891c 0x100d995d8 0x100d98758 0x100d995a4 0x100da5894 0x100da4eb0 0x21e5f4a0c 0x21e5f4aac)
libc++abi: terminating due to uncaught exception of type NSException
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[CBDescriptor service]: unrecognized selector sent to instance 0x128ac2400'
*** First throw call stack:
(0x193fff21c 0x191499abc 0x194069614 0x193f13a1c 0x193f13aa0 0x10b6c6c8c 0x10b6bda98 0x10b6c0538 0x1bd7cad94 0x1bd7caec4 0x1bd7c7a18 0x1bd786a40 0x1bd78422c 0x1bd784114 0x100d90584 0x100daa064 0x100d9891c 0x100d995d8 0x100d98758 0x100d995a4 0x100da5894 0x100da4eb0 0x21e5f4a0c 0x21e5f4aac)
terminating due to uncaught exception of type NSException
Message from debugger: killed

@hamidmalek hamidmalek requested review from twyatt and a team as code owners July 10, 2025 13:19
@hamidmalek hamidmalek requested a review from Phoenix7351 July 10, 2025 13:19
Copy link
Member

@twyatt twyatt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, it isn't clear to me how this PR is resolving the failure described in the PR description:

-[CBDescriptor service]: unrecognized selector sent to instance 0x128ac2400

The error describes trying to invoke service function on a CBDescriptor but this PR seems to be addressing nullability issues, of which we'd see a different error for if we had a nil reference problem?

@hamidmalek
Copy link
Author

Apologies, it isn't clear to me how this PR is resolving the failure described in the PR description:

Not at all. Not using of !! is just something to make it more robust, but the change that prevent the code from crash is to use the parent class and then log it based on its type.

@twyatt
Copy link
Member

twyatt commented Jul 17, 2025

use the parent class and then log it based on its type

I see. Everywhere we use detail the variables are typed. Is this an issue with the Kotlin compiler not catching a mismatch of types? I'm trying to understand how the wrong reference type is ending up in the logging function.

@twyatt twyatt added apple patch Changes that should bump the PATCH version number labels Jul 17, 2025
@hamidmalek
Copy link
Author

use the parent class and then log it based on its type

I see. Everywhere we use detail the variables are typed. Is this an issue with the Kotlin compiler not catching a mismatch of types? I'm trying to understand how the wrong reference type is ending up in the logging function.

TBH, I don't know when exactly this matching happens, so that mismatch was not traceable for me. I just tested this code and it was not producing any issues, so I concluded maybe it's a mismatch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apple patch Changes that should bump the PATCH version number
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants