fix crash on ios LogMessage

[hamidmalek]

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

[twyatt]

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]

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]

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.

[hamidmalek]

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.

[davertay-j]

I think the fix here is barking up the wrong tree, and this is a second case, or related instance of #1118. The failure smells of zombies and the selector is being dispatched to a stale pointer that happens to house a CBDescriptor class at invocation time.

If you could reproduce with NSZombieEnabled=YES plus MallocScribble=1 enabled that would prove/disprove zombies? And if at all possible attach a crash report so we can see if the stack frame is invoked from within CoreBluetooth or from the Kotlin runtime.

I suspect (weakly, just guessing) this may be originating in Connection.kt where we have a non-reentrant walk of captured services/descriptor lists with multiple suspension points. CoreBluetooth may replace its CBService / CBCharacteristic / CBDescriptor objects on every discovery pass and on service invalidation, so the tree in theory could become stale during the discovery loop, and we walk an invalid object graph and potentially capture bad pointers.

I concur that the !! here are a real danger regardless and need cleaning up. The CBCharacteristic.service and CBDescriptor.characteristic back-pointers are both @property(weak, readonly, nonatomic) so can become null at any time. The interop wrongly declares then nonnull which seems to be a common pitfall with Obj-C interop declarations.