I just upgraded one of my apps to Swift 5, I didn't change so much at all and there didn't seem to be any problems, so I just released it in production (fortunately in phased release).
After 1 days I started to see a very strange crash on Crashlytics that affect the 15% of people that is using my app.
This is the stack trace:
Crashed: com.apple.main-thread
0 (Missing) 0x31698aa1503e0 (Missing)
1 libswiftCore.dylib 0x1afa5ac68 _swift_release_dealloc + 28
2 App 0x104194c3c outlined consume of MyModel? + 4300033084
3 App 0x104482cb8 #objc MyController.__ivar_destroyer (<compiler-generated>)
4 libobjc.A.dylib 0x180f267cc object_cxxDestructFromClass(objc_object*, objc_class*) + 148
5 libobjc.A.dylib 0x180f366b8 objc_destructInstance + 68
6 libobjc.A.dylib 0x180f36720 object_dispose + 16
7 UIKitCore 0x1ae2edac0 -[UIResponder dealloc] + 152
8 UIKitCore 0x1add173e0 -[UIViewController dealloc] + 1748
9 App 0x10431d82c BaseViewController.__deallocating_deinit (MyController.swift:56)
10 App 0x10431d85c #objc BaseViewController.__deallocating_deinit (<compiler-generated>)
11 libobjc.A.dylib 0x180f41b9c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 672
12 CoreFoundation 0x181d59f40 _CFAutoreleasePoolPop + 28
13 CoreFoundation 0x181cd8e00 __CFRunLoopRun + 1932
14 CoreFoundation 0x181cd8354 CFRunLoopRunSpecific + 436
15 GraphicsServices 0x183ed879c GSEventRunModal + 104
16 UIKitCore 0x1ae2c3b68 UIApplicationMain + 212
17 App 0x104108468 main (AppDelegate.swift:21)
18 libdyld.dylib 0x18179e8e0 start + 4
I searched already something on the web but I find only a thread on the Swift Forum not very related to this.
MyModel is actually a struct model that is nested into another Model.
MyController is the very huge controller that manages the model.
The crash seems to happen obviously when popping the controller and so when the System tries to deallocate all the related properties.
I tried to replicate it many times with no results, and I didn't know really where to start looking.
Someone had the same problem?
UPDATE [Partially Fixed]:
It seemed to be a stack corruption caused by a Advertising Framework, to fix this I moved MyModel from Struct to Class, it's now on the Heap and can't get double freed.
From my experience, most of the outlined consume of errors are caused by concurrency issue. When one queue/thread reading the struct while another queue/thread modifying it without synchronization (mutex, semaphore, barrier, etc).
You need to check all threads stacks to see which thread access MyModel simultaneously with the Main(crashed) thread.
This is a question/answer. I found my issue which i will explain here hopefully for others to learn from as well, but i also have some questions regarding why.
I implemented IAP in my app and tested all of them in sandbox mode and everything worked as planned with no crashes anywhere. I eventually uploaded my app to the app store and after approval, i removed the development version from my device and installed the app store version. At which point, when i tried to go to my menu to test my Remove Ads IAP in production, the app crashes when loading the VC.
So i looked at my devices logs in Xcode...
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x0000000100054a34
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [0]
Triggered by Thread: 0
Filtered syslog:
None found
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 Connectify 0x0000000100054a34 specialized SettingsTableViewController.(viewDidLoad() -> ()).(closure #1) (SettingsTableViewController.swift:40)
1 Connectify 0x0000000100054e00 partial apply for SettingsTableViewController.(viewDidLoad() -> ()).(closure #1) (SettingsTableViewController.swift:0)
2 Connectify 0x00000001000283d0 thunk (IAPHelper.swift:0)
3 Connectify 0x000000010002b990 specialized IAPHelper.productsRequest(SKProductsRequest, didReceive : SKProductsResponse) -> () (IAPHelper.swift:0)
4 Connectify 0x0000000100028738 #objc IAPHelper.productsRequest(SKProductsRequest, didReceive : SKProductsResponse) -> () (IAPHelper.swift:0)
5 StoreKit 0x000000019ae39dbc __34-[SKProductsRequest _handleReply:]_block_invoke + 512
6 libdispatch.dylib 0x000000018d229200 _dispatch_call_block_and_release + 24
7 libdispatch.dylib 0x000000018d2291c0 _dispatch_client_callout + 16
8 libdispatch.dylib 0x000000018d22dd6c _dispatch_main_queue_callback_4CF + 1000
9 CoreFoundation 0x000000018e34bf2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
10 CoreFoundation 0x000000018e349b18 __CFRunLoopRun + 1660
11 CoreFoundation 0x000000018e278048 CFRunLoopRunSpecific + 444
12 GraphicsServices 0x000000018fcfe198 GSEventRunModal + 180
13 UIKit 0x00000001942642fc -[UIApplication _run] + 684
14 UIKit 0x000000019425f034 UIApplicationMain + 208
15 Connectify 0x0000000100021248 main (AppDelegate.swift:16)
16 libdyld.dylib 0x000000018d25c5b8 start + 4
Which lead me to believe it has to do with IAP's. This code is in viewDidLoad of my SettingsTableViewController.
products = []
Products.store.requestProducts{success, products in
if success {
self.products = products!
for i in 0...products!.count - 1{
print("Index \(i): \(products![i].productIdentifier)")
}
if !IAPHelper.canMakePayments() || Products.store.isProductPurchased(Products.RemoveAds){
self.cell1.textLabel?.textColor = UIColor.gray
self.cell1.isUserInteractionEnabled = false
self.cell1.accessoryType = .none
self.cell2.textLabel?.textColor = UIColor.gray
self.cell2.isUserInteractionEnabled = false
self.cell2.accessoryType = .none
}
}else{
print("Not success")
}
}
But i can't decipher enough of the crash log to determine what the issue is, only that it probably has to do with this block of code.
The revalation
So, at a loss, i had my wife download the app from the store and test for this crash. It did not! No crash at all. It was at this point I thought to try removing my device from the Dev Portal. And of course, that fixed it.
Conclusion/Questions
If you're using IAP's, which work in debug build testing, but not in production release on the same device. Disable your device in the Dev Portal and re-install from the store.
1) How is Apple deciding when the IAP should be sandboxed? Is it certificate based? Is it if the device ID is registered as a development device?
2) Why would this IAP code work in a debug build on my development device, but not with a release build? (Until i disabled the device in the DevPortal)
3) What information can be gathered from the crash log that would pin point this issue more accurately?
UPDATE
After reading more into EXC_BREAKPOINT (SIGTRAP) when it comes to Swift, i think it it's most likely related to an index out of bounds exception in the Products array. Specifically, as the crash report says, this line...
for i in 0...products!.count - 1{
But why would products be nil just because the development device is requesting IAPs from the production server?
Been encountering this error a lot in my OS X using swift:
"This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes. This will cause an exception in a future release."
I have a my NSWindow and I'm swapping in views to the contentView of the window. I get the error when I try and do a NSApp.beginSheet on the window, or when I add a subview to the window. Tried disabling autoresize stuff, and I don't have anything using auto layout. Any thoughts?
Sometimes it's fine and nothing happens, other times it totally breaks my UI and nothing loads
It needs to be placed inside a different thread that allows the UI to update as soon as execution of thread function completes:
Modern Swift:
DispatchQueue.main.async {
// Update UI
}
Older versions of Swift, pre Swift 3.
dispatch_async(dispatch_get_main_queue(){
// code here
})
Objective-C:
dispatch_async(dispatch_get_main_queue(), ^{
// code here
});
You get similar error message while debugging with print statements without using 'dispatch_async'
So when you get that error message, its time to use
Swift 4
DispatchQueue.main.async { //code }
Swift 3
DispatchQueue.main.async(){ //code }
Earlier Swift versions
dispatch_async(dispatch_get_main_queue()){ //code }
The "this application is modifying the autolayout engine from a background thread" error is logged in the console long after the actual problem occured, so debugging this can be hard without using a breakpoint.
I used #markussvensson's answer to detect my problem and found it using this Symbolic Breakpoint (Debug > Breakpoints > Create Symbolic Breakpoint):
Symbols: [UIView layoutIfNeeded] or [UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
Build and run the app on the emulator and replicate the steps that lead to the error message being thrown (the app will be slower than usual!). Xcode will then stop the app and mark the line of code (e.g. the call of a func) that's accessing the UI from a background thread.
When you try to update a text field value or adding a subview inside a background thread, you can get this problem. For that reason, you should put this kind of code in the main thread.
You need to wrap methods that call UI updates with dispatch_asynch to get the main queue. For example:
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.friendLabel.text = "You are following \(friendCount) accounts"
})
EDITED - SWIFT 3:
Now, we can do that following the next code:
// Move to a background thread to do some long running work
DispatchQueue.global(qos: .userInitiated).async {
// Do long running task here
// Bounce back to the main thread to update the UI
DispatchQueue.main.async {
self.friendLabel.text = "You are following \(friendCount) accounts"
}
}
For me, this error message originated from a banner from Admob SDK.
I was able to track the origin to "WebThread" by setting a conditional breakpoint.
Then I was able to get rid of the issue by encapsulating the Banner creation with:
dispatch_async(dispatch_get_main_queue(), ^{
_bannerForTableFooter = [[GADBannerView alloc] initWithAdSize:kGADAdSizeSmartBannerPortrait];
...
}
I don't know why this helped as I cannot see how this code was called from a non-main-thread.
Hope it can help anyone.
I had this problem since updating to the iOS 9 SDK when I was calling a block that did UI updates within an NSURLConnection async request completion handler. Putting the block call in a dispatch_async using dispatch_main_queue solved the issue.
It worked fine in iOS 8.
Had the same problem because I was using performSelectorInBackground.
Main problem with "This application is modifying the autolayout engine from a background thread" is that it seem to be logged a long time after the actual problem occurs, this can make it very hard to troubleshoot.
I managed to solve the issue by creating three symbolic breakpoints.
Debug > Breakpoints > Create Symbolic Breakpoint...
Breakpoint 1:
Symbol: -[UIView setNeedsLayout]
Condition: !(BOOL)[NSThread isMainThread]
Breakpoint 2:
Symbol: -[UIView layoutIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
Breakpoint 3:
Symbol: -[UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
With these breakpoints, you can easily get a break on the actual line where you incorrectly call UI methods on non-main thread.
You must not change the UI offside the main thread! UIKit is not thread safe, so that above problem and also some other weird problems will arise if you do that. The app can even crash.
So, to do the UIKit operations, you need to define block and let it be executed on the main queue: such as,
NSOperationQueue.mainQueue().addOperationWithBlock {
}
Obviously you are doing some UI update on back ground thread. Cant predict exactly where, without seeing your code.
These are some situations it might happen:-
you might be doing something on background thread and not using. Being in the same function this code is easier to spot.
DispatchQueue.main.async { // do UI update here }
calling a func doing web request call on background thread and its completion handler calling other func doing ui update.
to solve this try checking code where you have updated the UI after webrequest call.
// Do something on background thread
DispatchQueue.global(qos: .userInitiated).async {
// update UI on main thread
DispatchQueue.main.async {
// Updating whole table view
self.myTableview.reloadData()
}
}
I had this issue while reloading data in UITableView. Simply dispatching reload as follows fixed the issue for me.
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.tableView.reloadData()
})
I had the same problem. Turns out I was using UIAlerts that needed the main queue. But, they've been deprecated.
When I changed the UIAlerts to the UIAlertController, I no longer had the problem and did not have to use any dispatch_async code. The lesson - pay attention to warnings. They help even when you don't expect it.
You already have the correct code answer from #Mark but, just to share my findings:
The issue is that you are requesting a change in the view and assuming that it will happen instantly. In reality, the loading of a view depends on the available resources. If everything loads quickly enough and there are no delays then you don't notice anything. In scenarios, where there is any delay due to the process thread being busy etc, the application runs into a situation where it is supposed to display something even though its not ready yet. Hence, it is advisable to dispatch these requests in a asynchronous queues so, they get executed based on the load.
I had this issue when I was using TouchID if that helps anyone else, wrap your success logic which likely does something with the UI in the main queue.
It could be something as simple as setting a text field / label value or adding a subview inside a background thread, which may cause a field's layout to change. Make sure anything you do with the interface only happens in the main thread.
Check this link: https://forums.developer.apple.com/thread/7399
I had the same issue when trying to update error message in UILabel in the same ViewController (it takes a little while to update data when trying to do that with normal coding). I used DispatchQueue in Swift 3 Xcode 8 and it works.
If you want to hunt this error, use the main thread checker pause on issues checkbox.
Fixing it is easy most of the times, dispatching the problematic line in the main queue.
For me the issue was the following.
Make sure performSegueWithIdentifier: is performed on the main thread:
dispatch_async (dispatch_get_main_queue(), ^{
[self performSegueWithIdentifier:#"ViewController" sender:nil];
});
Swift 4,
Suppose, if you are calling some method using operation queue
operationQueue.addOperation({
self.searchFavourites()
})
And suppose function searchFavourites is like,
func searchFavourites() {
DispatchQueue.main.async {
//Your code
}
}
if you call, all code inside the method "searchFavourites" on the main thread, it will still give an error if you are updating some UI in it.
This application is modifying the autolayout engine from a background
thread after the engine was accessed from the main thread.
So use solution,
operationQueue.addOperation({
DispatchQueue.main.async {
self.searchFavourites()
}
})
For this kind of scenario.
Here check out this line from the logs
$S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
you can check that which function calling from the either background thread or where you are calling api method you need to call your function from the main thread like this.
DispatchQueue.main.async { func()}
func() is that function you want to call in the result of api call
success or else.
Logs Here
This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
Stack:(
0 Foundation 0x00000001c570ce50 <redacted> + 96
1 Foundation 0x00000001c5501868 <redacted> + 32
2 Foundation 0x00000001c5544370 <redacted> + 540
3 Foundation 0x00000001c5543840 <redacted> + 396
4 Foundation 0x00000001c554358c <redacted> + 272
5 Foundation 0x00000001c5542e10 <redacted> + 264
6 UIKitCore 0x00000001f20d62e4 <redacted> + 488
7 UIKitCore 0x00000001f20d67b0 <redacted> + 36
8 UIKitCore 0x00000001f20d6eb0 <redacted> + 84
9 Foundation 0x00000001c571d124 <redacted> + 76
10 Foundation 0x00000001c54ff30c <redacted> + 108
11 Foundation 0x00000001c54fe304 <redacted> + 328
12 UIKitCore 0x00000001f151dc0c <redacted> + 156
13 UIKitCore 0x00000001f151e0c0 <redacted> + 152
14 UIKitCore 0x00000001f1514834 <redacted> + 868
15 UIKitCore 0x00000001f1518760 <redacted> + 104
16 UIKitCore 0x00000001f1543370 <redacted> + 1772
17 UIKitCore 0x00000001f1546598 <redacted> + 120
18 UIKitCore 0x00000001f14fc850 <redacted> + 1452
19 UIKitCore 0x00000001f168f318 <redacted> + 196
20 UIKitCore 0x00000001f168d330 <redacted> + 144
21 AppName 0x0000000100b8ed00 $S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
22 AppName 0x0000000100b8d9f4 $S12CcfU0_y10Foundation4DataVSg_So13NSURLResponseCSgs5Error_pSgtcfU_ + 2384
23 App NAme 0x0000000100a98f3c $S10Foundation4DataVSgSo13NSURLResponseCSgs5Error_pSgIegggg_So6NSDataCSgAGSo7NSErrorCSgIeyByyy_TR + 316
24 CFNetwork 0x00000001c513aa00 <redacted> + 32
25 CFNetwork 0x00000001c514f1a0 <redacted> + 176
26 Foundation 0x00000001c55ed8bc <redacted> + 16
27 Foundation 0x00000001c54f5ab8 <redacted> + 72
28 Foundation 0x00000001c54f4f8c <redacted> + 740
29 Foundation 0x00000001c55ef790 <redacted> + 272
30 libdispatch.dylib 0x000000010286f824 _dispatch_call_block_and_release + 24
31 libdispatch.dylib 0x0000000102870dc8 _dispatch_client_callout + 16
32 libdispatch.dylib 0x00000001028741c4 _dispatch_continuation_pop + 528
33 libdispatch.dylib 0x0000000102873604 _dispatch_async_redirect_invoke + 632
34 libdispatch.dylib 0x00000001028821dc _dispatch_root_queue_drain + 376
35 libdispatch.dylib 0x0000000102882bc8 _dispatch_worker_thread2 + 156
36 libsystem_pthread.dylib 0x00000001c477917c _pthread_wqthread + 472
37 libsystem_pthread.dylib 0x00000001c477bcec start_wqthread + 4
)
I also encountered this problem, seeing a ton of these messages and stack traces being printed in the output, when I resized the window to a smaller size than its initial value. Spending a long time figuring out the problem, I thought I'd share the rather simple solution. I had once enabled Can Draw Concurrently on an NSTextView through IB. That tells AppKit that it can call the view's draw(_:) method from another thread. After disabling it, I no longer got any error messages. I didn't experience any problems before updating to macOS 10.14 Beta, but at the same time, I also started modifying the code to perform work with the text view.
Our App has Map and GPS based location tracking functionality. This app is already uploaded on Apple Store. The App contains following feature:
Map Shows real-time traffic data Shows real-time traffic event (Accident, Traffic Jam etc.)
User’s GPS location tracking
The application runs fine for the iOS versions 5 and 6.
We are facing following crashing issue for iOS 7 Beta while operating Map functionality in the app. We have used the following features of iOS to render the traffic data and traffic event on Map:
MKAnnotation to render the traffic event
To render the traffic data, app is using the CGBitmapContextCreate function.
context = CGBitmapContextCreate (NULL,
self.mapView.frame.size.width,
self.mapView.frame.size.height,
8,// bits per component
bitmapBytesPerRow,
colorSpace,
kCGImageAlphaPremultipliedLast);
CGContextSetAllowsAntialiasing (context,YES)
Draw the line to display the traffic data on the Bitmap context.
Created bitmap context will be displayed on map using the MKAnnotation API.
App uses the NSOperationQueue to render the traffic and event data because the user interaction with map is smooth. Following is the snippet of the code:
[queue addOperationWithBlock:^{ [Set the required data], [Update the UI] }];
Following are two crash logs which gets generated while random operation n of the Map functionality.
Crash Log - 1
Incident
Identifier: 471EAE21-E118-4E3D-AAAE-D7D82B1D6326
CrashReporter
Key:
bdbf75eb30240449214769478f38830aa7a14f7f
Hardware
Model: iPhone5,2
Process: {Application Name} [246]
Path: /var/mobile/Applications/4FA0A7F2-4998-4F8F-A4C6-66D849D074B8/{Application Name}.app/{Application Name}
Identifier: {Application bunald name}
Version: X.X.X.X
Code
Type: ARM (Native)
Parent
Process: launchd [1]
Date/Time: 2013-08-30 14:21:24.523 +0530
OS
Version: iOS 7.0 (11A4449d)
Report
Version: 104
Exception
Type: EXC_BAD_ACCESS (SIGSEGV)
Exception
Subtype: KERN_INVALID_ADDRESS at 0x8000000c
Triggered
by Thread: 0
Thread
0 Crashed:
0 libobjc.A.dylib 0x38ed3b66
objc_msgSend + 6
1 CoreFoundation 0x2ede773c -[__NSSetM removeObject:] + 92
2 MapKit 0x3002de96 -[MKAnnotationManager
_removeRepresentationForAnnotation:fromCull:] + 490
3 MapKit 0x3004bc54 -[MKAnnotationManager
_removeAnnotation:updateVisible:removeFromContainer:] + 272
4 MapKit 0x3004bb38 -[MKAnnotationManager removeAnnotation:] + 24
5 SLIM 0x00165828 -[TravelStarViewController
mapView:viewForAnnotation:] (TravelStarViewController.m:1735)
6 MapKit 0x3005ea86 -[MKMapView
annotationManager:representationForAnnotation:] + 74
7 MapKit 0x3002a136 -[MKAnnotationManager _addRepresentationForAnnotation:]
+ 362
8 MapKit 0x30028c4a -[MKAnnotationManager updateVisibleAnnotations] +
1034
9 Foundation 0x2f876358 __NSFireTimer + 60
10 CoreFoundation 0x2ee7ae84 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
+ 12
11 CoreFoundation 0x2ee7aa9e __CFRunLoopDoTimer + 790
12 CoreFoundation 0x2ee78e26 __CFRunLoopRun + 1214
13 CoreFoundation 0x2ede353c CFRunLoopRunSpecific + 520
14 CoreFoundation 0x2ede331e CFRunLoopRunInMode + 102
15 GraphicsServices 0x3387733e
GSEventRunModal + 134
16 UIKit 0x313fc7b0 UIApplicationMain + 1132
17 SLIM 0x000f3fa6
main (main.m:15)
18 SLIM 0x000f3efc start + 36
I think it may be that traffic events are coming in and taking to long in NSOperation. The operation could start, and then be referencing map graphical elements that no longer exist in the MapView. For instance, the user could be scrolling the map, and the NSOperation could "queue" up, and then end when the target region is out of view. The crash is clearly a memory violation. Commonly caused by code trying to access memory that was freed.
I would suggest that you look into your use of NSOperationQueue. I can see how it would make the map interaction smoother, and that part may be OK, but coupled with the "events" could be causing problems.
From the crash I can see that it is running on a CFRunLoop and a NSTimer is firing. NSTimers are notorious for not stopping fully in Objective C. When they finally fire off, the elements they work with are commonly done and freed their memory.
I have developed an iPhone application which plays different music files. Everything is working fine except when an incoming phone call interrupts the playback. This crashes the app with the following log:
START CRASH LOG
Thread 0 Crashed:
0 libobjc.A.dylib 0x32d98f20 objc_msgSend + 20
1 AVFoundation 0x30739ddc AVAudioSessionPropertyListener(void*, unsigned long, unsigned long, void const*) + 284
2 AudioToolbox 0x36d78bec SSServer_AudioSessionInterruptionListenerMessage + 316
3 AudioToolbox 0x36d017bc _XAudioSessionInterruptionListenerMessage + 128
4 AudioToolbox 0x36c68584 mshMIGPerform + 224
5 CoreFoundation 0x3752f5c4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 22
6 CoreFoundation 0x3752f582 __CFRunLoopDoSource1 + 158
7 CoreFoundation 0x3752182e __CFRunLoopRun + 574
8 CoreFoundation 0x37521504 CFRunLoopRunSpecific + 220
9 CoreFoundation 0x37521412 CFRunLoopRunInMode + 54
10 GraphicsServices 0x33e76d1c GSEventRunModal + 188
11 UIKit 0x3591d574 -[UIApplication _run] + 580
12 UIKit 0x3591a550 UIApplicationMain + 964
END CRASH LOG
I have narrowed it down to a call in the applicationWillResignActive method in the app delegate, but I can't seem to figure it out because if the app goes to background mode (by pressing the home button) the app works correctly, it only crashes when a phone call is received.
The line which causes the crash in the applicationWillResignActive method is:
[navController popToRootViewControllerAnimated:NO]; //navController is an instance of UINavigationController; i used this statement to remove all view controllers and when the app resumes, I push the first view controller so that the app starts from the beginning.
Does anyone have an idea why this crash occurs only when a phone call is received ?
We've just been tracking a very similar crash.
Ours turn out to be as described here:
https://github.com/mattgallagher/AudioStreamer/issues/6
In particular, MyAudioSessionInterruptionListener (or the name of the callback passed to
AudioSessionInitialize) and it's inClientData can not be changed after it's been registered, so the callback must always do something sensible even if the underlying object has been deallocated.
The solution suggested for AudioStream is to use a static variable, and make sure it points to the object that is currently interested in the callback, and never points at a deallocated object - the important thing is not to use inClientData.