0

Getting a strange crash fairly commonly among iPhones sending data between each other over bluetooth. After a lot of effort I still cannot reproduce it in the debugger.

Crash log:

NSInternalInconsistencyException
Invalid parameter not satisfying: request != nil

3 Foundation 0x0000000186d28ed4 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 108
4 CoreBluetooth 0x0000000185aec808 -[CBPeripheralManager respondToRequest:withResult:] + 156
5 CoreBluetooth 0x0000000185aee410 -[CBPeripheralManager handleSetAttributeValues:] + 1104

Don't know what triggers the peripheral manager to call handleSetAttributeValues or where the nil value is coming from here.

There is only one place in the codebase where I call [CBPeripheralManager respondToRequest:withResult:] and I have safeguards around it to ensure that it will never get called if request is nil.

Trespassers W
  • 379
  • 1
  • 5
  • 14
  • the request can still become `nil`if a `weak` to it goes out of scope, maybe this is the case? – Michał Ciuba Jul 28 '15 at 09:20
  • @MichałCiuba I don't think that's the case, as the request comes in as part of an array "requests" that is an argument to the function that directly calls respondToRequest. This function is a callback from CoreBluetooth. - (void)peripheralManager:(CBPeripheralManager *)peripheral didReceiveWriteRequests:(NSArray *)requests – Trespassers W Jul 29 '15 at 08:30
  • @TrespassersW did you solve this problem? I have exactly the same results in crash list. I didn't find in documentation how to create/mockup CBAttrRequest object or any evidence of necessity of calling respondToRequest every time when didReceive delegate method called. – gaussblurinc Apr 12 '16 at 10:03
  • @TrespassersW I suppose that if you don't call respondToRequest, it will be called somewhere in guts of bluetooth with default ( request == nil ) parameters. – gaussblurinc Apr 12 '16 at 10:05

0 Answers0