Assistance with back trace

The backtrace was too large to add so I've added it in its entirety here https://pastebin.com/SmrpwrkY

The backtrace was too large to add so I've added it in its entirety …

I can’t do much with third-party crash reports [1]. Do you have an Apple crash report for this? If so, please post it here, using the instructions from Posting a Crash Report.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] For an explanation as to why, see Implementing Your Own Crash Reporter.

Hi @eskimo

Thanks for the reply.

I've attached the crash log which I took from XCode.

Any assistance is greatly appreciated

Thanks for the crash report.

That was from iOS 16.1.1. It sounds like you’re seeing a lot of these crashes. Are they all from older versions of iOS 16? Or do you have any from a more recent version? If so, can you post one of those?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

My app would have no crashes if it were not for this crash. On average the crash occurs 5 times a week.

The most recent version of iOS this crash has happened on is 16.6. It looks like it has occurred on every version of IOS 16.

I've added a crash log for iOS 16.6

Thanks for the new crash report.

Consider the crashing thread backtrace:

Thread 8 name:
Thread 8 Crashed:
0   libsystem_platform.dylib … _os_unfair_lock_recursive_abort + 36 (lock.c:508)
1   libsystem_platform.dylib … _os_unfair_lock_lock_slow + 284 (lock.c:567)
2   CoreFoundation           … CFSocketInvalidate + 132 (CFSocket.c:1719)
3   CFNetwork                … Schedulables::_SchedulablesInvalidateApplierFunction(void const*, void*) + 36 (S…
4   CoreFoundation           … CFArrayApplyFunction + 72 (CFArray.c:674)
5   CFNetwork                … SocketStream::~SocketStream() + 448 (SocketStream.cpp:737)
6   CoreFoundation           … _CFRelease + 284 (CFRuntime.c:2108)
7   CoreFoundation           … CFSocketInvalidate + 952 (CFSocket.c:1782)
8   CFNetwork                … SocketStream::close(void const*) + 488 (SocketStream.cpp:1447)
9   CoreFoundation           … _CFStreamClose + 108 (CFStream.c:309)
10  CocoaAsyncSocket         … -[GCDAsyncSocket closeWithError:] + 200 (GCDAsyncSocket.m:3120)
11  CocoaAsyncSocket         … -[GCDAsyncSocket doReadEOF] + 292 (GCDAsyncSocket.m:5586)
12  CocoaAsyncSocket         … __66-[GCDAsyncSocket setupReadAndWriteSourcesForNewlyConnectedSocket:]_block_inv…
13  libdispatch.dylib        … _dispatch_client_callout + 20 (object.m:560)

Your code in frame 10 has closed a socket stream. That eventually gets to CFSocketInvalidate, which is trying to take an lock. This has trapped because the lock is already held by the current thread (note that frame 0 is _os_unfair_lock_recursive_abort).

CFSocket has a lot of locks, and it’s not clear what lock is involved. Some spelunking at my end confirms that this is the __CFAllSocketsLock lock, as shown by this line.

IMPORTANT This the Swift open source, which is not the same as the source used to build iOS. Notably, it’s still using a legacy lock, whereas iOS has been updated to use os_unfair_lock.

I can’t see this being anything than an OS bug. __CFAllSocketsLock is entirely internal to CFSocket, so I can’t see any way for you to be holding on to it. It must be being held by system code, that is, frames 9 through 2. Honestly, frame 7 seems like a likely candidate |-:

You should definitely file a bug about this. Please post your bug number, just for the record.

However, the API you’re using, CFSocketStream, has already been marked for deprecation, and I think this would be a great excuse to get off it. What are you using CFSocketStream for? To run a TCP connection? If so, the direct replacement is NWConnection.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi @eskimo

Your thorough investigation is appreciated.

For context I am using rabbit client. This library uses GCDAsyncSocket.

Unfortunately we are bound to use this library for the medium term because of the development effort required to modify our comms with our backend services.

I filed a bug using Feedback Assistant. The reference is FB13091139

I filed a bug using Feedback Assistant. The reference is FB13091139

Thanks for that.

Can you think of any recommended way from apple to use RMQ client side that would leverage apple API's not flagged for deprecation?

RabbitMQ is an implementation of the AMQP protocol, right? AFAIK there’s no Apple API that implements that. However, this is very server-y, so you might find a solution in the Swift-on-server space. Such packages are generally implemented on top of SwiftNIO, and Swift NIO Transport Services lets you run SwiftNIO over Network framework.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I feedback from the bug I filed with apple.

The most likely cause is that the CFSocketStream has been overreleased by the app. 
CFSocketInvalidate should not cause SocketStream to be deallocated inline since it took an extra retain on itself before calling CFSocketInvalidate.

It is most probably bug in iOS 16: https://github.com/robbiehanson/CocoaAsyncSocket/issues/803