ObjCRuntime.RuntimeException when hooking CBPeripheral events

[divil5000]

Apple platform

iOS

Framework version

net8.0-*

Affected platform version

VS2022 17.13.6

Description

Our app makes use of Bluetooth LE, and continuously attempts to connect to a local device when the user has configured it. If the user forgets to turn the device on, or their device is not with them, intended behaviour is to keep trying to connect to it so that when it becomes available, the connection succeeds.

Every time we attempt to make a connection, we get a new or existing CBPeripheral from CBCentralManager.RetrievePeripheralsWithIdentifiers, hook its events, then try to connect to it. After a given timeout, we clean everything up, including unhooking the events before calling CBCentralManager.CancelPeripheralConnection. Then after a short interval the connection process is started again fresh.

We are seeing that after trying to do this over 200 attempts, the runtime crashes with the stack trace below.

ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x114616380 (type: CoreBluetooth_CBPeripheral__CBPeripheralDelegate). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'CoreBluetooth.CBPeripheral+_CBPeripheralDelegate' does not have a constructor that takes one NativeHandle argument).
at ObjCRuntime.Runtime.MissingCtor(IntPtr , IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution , IntPtr , RuntimeMethodHandle )
at ObjCRuntime.Runtime.ConstructNSObject[NSObject](IntPtr , Type , MissingCtorResolution )
at ObjCRuntime.Runtime.ConstructNSObject(IntPtr , IntPtr , MissingCtorResolution )
at ObjCRuntime.Runtime.GetNSObject(IntPtr , MissingCtorResolution , Boolean )
at ObjCRuntime.Runtime.GetNSObject(NativeHandle )
at CoreBluetooth.CBPeripheral.EnsureCBPeripheralDelegate()
at CoreBluetooth.CBPeripheral.add_DiscoveredService(EventHandler`1 )

As you can see, we are using the built-in events on CBPeripheral rather than attaching our own delegate to it. Perhaps this has something to do with the exception. I would like to know under what circumstances you'd expect to see this exception.

Steps to Reproduce

I do not have a simple repro project. While I might be able to create one, I would rather someone looked at the stack trace and gave me some preliminary advice if possible.

Did you find any workaround?

No response

Relevant logs

No response

[rolfbjarne]

This looks like this issue: https://web.archive.org/web/20170630214134/https://bugzilla.xamarin.com/show_bug.cgi?id=34242

Can you try the workaround at the end of the comment here: https://web.archive.org/web/20170630214134/https://bugzilla.xamarin.com/show_bug.cgi?id=34242#c9 and see if that works for you?

---

Copying the comment here:

This is what happens:

1. OnDiscoveredPeripheral is called, a CBDiscoveredPeripheralEventArgs instance containing a CBPeripheral instance is passed in.
2. OnDiscoveredPeripheral adds an event handler to the CBPeripheral instance. This will create an instance of an internal delegate (_CBPeripheralDelegate) that handles the event, and store this object as a field on the CBPeripheral instance. In this process the CBPeripheral instance is "marked dirty", which means that the GC will only free it if native code does not reference the instance anymore.
3. Native code creates a weak reference to the CBPeripheral instance.
4. The GC runs, and sees that native code does not retain the CBPeripheral instance (there's only a weak reference, which is invisible to the GC), and thus the CBPeripheral instance is scheduled for collection. By extension the _CBPeripheralDelegate instance is also scheduled for collection, and subsequently collected. Apparently only the _CBPeripheralDelegate instance is collected, and not the CBPeripheral instance (the GC is allowed to not collect everything; this is not a bug).
5. Native code reads the weak reference to the CBPeripheral instance, and calls OnDiscoveredPeripheral again.
6. OnDiscoveredPeripheral tries to add an event handler again, but runs into the ObjC marshalling exception because the internal delegate instance has been collected.

The workaround is to keep the CBPeripheral instances you care about visible to the GC in managed code (put in them in a list for instance). This way step 4 above doesn't happen.

[divil5000]

I agree the issue looks similar on the face of it, however the workaround there of keeping all CBPeripherals around in a static list is a non-starter for us. That list would swiftly grow to hundreds, if not thousands of items.

Your suggestion is to keep the CBPeripheral instances we care about visible to the GC. That would be fine, because any that we care about ARE referenced in our code. As soon as we no longer care about them, their events are unhooked and they are dereferenced, making them liable for GC. We don't care about them any more. However, we obtain these CBPeripheral instances from CBCentralManager and it is not clear whether it is creating them or reusing them. It's possible that it gives us the same CBPeripheral instance under the covers, but I don't see why that should be a problem.

It sounds like your recommendation is to add the CBPeripheral instances to a static list, even when we are done with them and will never use them again? Is that really true?

[rolfbjarne]

I agree this is not a very good workaround.

One thing you could try would be to in addition to disconnecting the event handlers, set the delegate property to null:

CBPeripheral peripheral = ...;
peripheral.DiscoveredService -= ...;
peripheral.Delegate = null;

and see if that changes anything.

[divil5000]

That's a good idea, I will do that, as well as some other things. Thanks Rolf.