iOS App Freeze / Watchdog Termination in AIR SDK 51.2.2.7 (Regression from 51.2.2.6)

[Tuning3DT]

After upgrading to AIR SDK 51.2.2.7, our iOS app randomly freezes and becomes completely unresponsive. The UI stops responding to all input and the app remains frozen on screen. After some time, iOS terminates the app and a crash report prompt appears when reopening the app.

This issue does not occur with earlier AIR SDK versions.

Regression
Tested AIR SDK versions:

• 51.2.2.4 – Works correctly
• 51.2.2.6 – Works correctly
• 51.2.2.7 – App freezes and becomes unresponsive

This strongly suggests a regression introduced in 51.2.2.7.

Observed Behavior

• The app launches normally.
• After navigating through several screens, the app freezes.
• The UI becomes completely unresponsive.
• The app remains visible on screen and does not close immediately.
• After some time, iOS terminates the process.
• When reopening the app, the system shows the “app previously crashed” report prompt.

This behavior is consistent with an iOS watchdog termination caused by the main thread becoming unresponsive.

Expected Behavior
The app should remain responsive and behave the same as with AIR SDK 51.2.2.6.

Actual Behavior
The app eventually freezes and becomes unresponsive until iOS terminates it.

Termination Reason: FRONTBOARD 0x8BADF00D
<RBSTerminateContext| domain:10 code:0x8BADF00D explanation:
[app<com.3dtuning.Tuning3D>:35701] Failed to terminate gracefully after 5.0s
WatchdogEvent: process-exit
WatchdogVisibility: Foreground

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:

0   libsystem_kernel.dylib    __psynch_mutexwait
1   libsystem_pthread.dylib   _pthread_mutex_firstfit_lock_wait
2   libsystem_pthread.dylib   _pthread_mutex_firstfit_lock_slow
3   Foundation                -[NSRecursiveLock lock]

A crash report from the device is attached.

3DTuning-2026-03-05-133753.txt

[ajwfrost]

Thanks ..

Given the changes that went into iOS for 51.2.2.7, my assumption would be this is URL-related, and there is another thread where something is happening:

{"value":0}},"queue":"com.apple.NSURLSession-delegate","frames":[
{"imageOffset":28852,"symbol":"__psynch_mutexwait","symbolLocation":8,"imageIndex":8},
{"imageOffset":7316,"symbol":"_pthread_mutex_firstfit_lock_wait","symbolLocation":84,"imageIndex":9},
{"imageOffset":3244,"symbol":"_pthread_mutex_firstfit_lock_slow","symbolLocation":220,"imageIndex":9},
{"imageOffset":98184,"imageIndex":0},
{"imageOffset":1308708,"imageIndex":0},
{"imageOffset":1059848,"imageIndex":0},
{"imageOffset":904260,"imageIndex":0},
{"imageOffset":3301012,"imageIndex":0},
{"imageOffset":3301208,"imageIndex":0},
{"imageOffset":909040,"symbol":"__81-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:]_block_invoke","symbolLocation":168,"imageIndex":18},
{"imageOffset":6876,"symbol":"_dispatch_call_block_and_release","symbolLocation":32,"imageIndex":19},

I don't suppose you're able to reproduce this yourselves? It would be nice if we're able to symbolicate that call stack, which is possible if you use the IPA symbol generation thing, mentioned in https://airsdk.harman.com/support

thanks

[Tuning3DT]

Thanks for the quick follow-up. I’ve attached the crash log you requested along with the generated IPA symbol file (ipasyms.dat) and the dSYM bundle just in case they’re useful for symbolication.

I can consistently reproduce the issue on my side: simply opening the timeline or gallery screens a few times causes the app to freeze. These screens make heavy use of multiple URLLoader and URLRequest instances, so it seems aligned with your suspicion that the regression in 51.2.2.7 may be URL-related.

Please let me know if you need any additional logs or test cases—I can reproduce it reliably and am happy to provide more detail.

crash_report.zip

Thanks ..

Given the changes that went into iOS for 51.2.2.7, my assumption would be this is URL-related, and there is another thread where something is happening:

{"value":0}},"queue":"com.apple.NSURLSession-delegate","frames":[
{"imageOffset":28852,"symbol":"__psynch_mutexwait","symbolLocation":8,"imageIndex":8},
{"imageOffset":7316,"symbol":"_pthread_mutex_firstfit_lock_wait","symbolLocation":84,"imageIndex":9},
{"imageOffset":3244,"symbol":"_pthread_mutex_firstfit_lock_slow","symbolLocation":220,"imageIndex":9},
{"imageOffset":98184,"imageIndex":0},
{"imageOffset":1308708,"imageIndex":0},
{"imageOffset":1059848,"imageIndex":0},
{"imageOffset":904260,"imageIndex":0},
{"imageOffset":3301012,"imageIndex":0},
{"imageOffset":3301208,"imageIndex":0},
{"imageOffset":909040,"symbol":"__81-[__NSCFURLSessionDelegateWrapper dataTask:didReceiveResponse:completionHandler:]_block_invoke","symbolLocation":168,"imageIndex":18},
{"imageOffset":6876,"symbol":"_dispatch_call_block_and_release","symbolLocation":32,"imageIndex":19},

I don't suppose you're able to reproduce this yourselves? It would be nice if we're able to symbolicate that call stack, which is possible if you use the IPA symbol generation thing, mentioned in https://airsdk.harman.com/support

thanks

[Tuning3DT]

Hi @ajwfrost ! Just following up on this issue 🙂
Is there any update, or anything else I can provide to help?
Thanks!