0

I am writing an app that uses Audio Queue Services to play music. When it gets to the end of one song, it should move on to the next. It works fine in the debug scheme, but it crashes in the release scheme

Process:         xxx [1136]
Path:            /Users/USER/Desktop/btunes.app/Contents/MacOS/xxx
Identifier:      xxx
Version:         1.0 (1)
Code Type:       X86-64 (Native)
Parent Process:  launchd [152]
Responsible:     xxx [1136]
User ID:         501

Date/Time:       2014-03-18 09:33:15.557 -0700
OS Version:      Mac OS X 10.9.2 (13C64)
Report Version:  11
Anonymous UUID:  57FFD284-4D30-889E-73D0-CE978BAFC774


Crashed Thread:  6  com.apple.coreaudio.AQClient

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000280000018

VM Regions Near 0x280000018:
    CG shared images       00000001c7eb2000-00000001c7eba000 [   32K] r--/r-- SM=SHM  
--> 
    JS JIT generated code  00005b8cc8000000-00005b8cc8001000 [    4K] ---/rwx SM=NUL  

Application Specific Information:
objc_msgSend() selector name: delegate


Thread 6 Crashed:: com.apple.coreaudio.AQClient
0   libobjc.A.dylib                 0x00007fff85742097 objc_msgSend + 23
1   com.cluttered.btunes            0x000000010aced249 -[BTSAudioStreamer handleAudioQueueProperty] + 136 (BTSAudioStreamer.m:180)
2   com.apple.audio.toolbox.AudioToolbox    0x00007fff87af6f6d ClientAudioQueue::PropertyChanged(unsigned int) + 415
3   com.apple.audio.toolbox.AudioToolbox    0x00007fff87afc97c AQClientCallbackMessageReader::DispatchCallbacks(void const*, unsigned long) + 440
4   com.apple.audio.toolbox.AudioToolbox    0x00007fff87af742e ClientAudioQueue::FetchAndDeliverPendingCallbacks(unsigned int) + 334
5   com.apple.audio.toolbox.AudioToolbox    0x00007fff87af7554 AQCallbackReceiver_CallbackNotificationsAvailable + 129
6   com.apple.audio.toolbox.AudioToolbox    0x00007fff87b1777c _XCallbackNotificationsAvailable + 48
7   com.apple.audio.toolbox.AudioToolbox    0x00007fff87b111bf mshMIGPerform + 153
8   com.apple.CoreFoundation        0x00007fff81adc9a9 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
9   com.apple.CoreFoundation        0x00007fff81adc91e __CFRunLoopDoSource1 + 478
10  com.apple.CoreFoundation        0x00007fff81acda16 __CFRunLoopRun + 1830
11  com.apple.CoreFoundation        0x00007fff81acd0b5 CFRunLoopRunSpecific + 309
12  com.apple.audio.toolbox.AudioToolbox    0x00007fff87afe479 GenericRunLoopThread::Entry(void*) + 187
13  com.apple.audio.toolbox.AudioToolbox    0x00007fff87ab7c0d CAPThread::Entry(CAPThread*) + 109
14  libsystem_pthread.dylib         0x00007fff87db1899 _pthread_body + 138
15  libsystem_pthread.dylib         0x00007fff87db172a _pthread_start + 137
16  libsystem_pthread.dylib         0x00007fff87db5fc9 thread_start + 13

Line 180 is

if (self.delegate) {

The delegate is (weak), and I set self.delegate to nil in dealloc. It looks like the Audio Queue Property Listener keeps running even after I remove it (which I'm also doing in dealloc).

I don't understand why it only happens in Release mode though. For now I'm just archiving the app in Debug but this obviously not ideal. Any ideas?

jsd
  • 7,673
  • 5
  • 27
  • 47
  • I've had a similar problem just recently (not with Audio) but I'm tempted to say there's a bug in XCode 5.0.2. – l'L'l Mar 18 '14 at 16:50
  • 1
    http://www.mindjuice.net/2011/11/30/how-to-fix-an-app-that-crashes-in-release-but-not-debug/ – FlavorScape Mar 18 '14 at 17:12
  • @FlavorScape, That looks like it was the issue for me; Although the tip did not say if optimization was kept on `none` for release. Incidentally, I tried to set optimization for only `fast` and the release version crashed. So it looks like `none` is the only choice here. I've never experienced this before, so I don't understand why it's suddenly affecting the release versions of apps that have been compiling exactly the same as before. – l'L'l Mar 18 '14 at 17:26

1 Answers1

2

Paraphrasing/Quoting this post so that the knowledge is retained.

Looks like there is an issue with different optimization levels. Running with optimization at fast causes a crash in some environments.

"One of the differences that jumped out at me was the Optmization Level setting. The Debug version was set to None [-O0], while the Release version was set to Fastest, Smallest [-Os].

I changed the Debug setting to Fastest, Smallest [-Os] and BOOM, it crashed on the iPhone 3G every time I ran it. Switching it back to None [-O0] brought back the correct behavior."

Also see Related SO Question.

Community
  • 1
  • 1
FlavorScape
  • 13,301
  • 12
  • 75
  • 117
  • Any idea of why having the optimization on would cause the issue in the first place? – l'L'l Mar 18 '14 at 18:25
  • Try running the debug version in fast mode. Then see what particular module is causing the problem. – FlavorScape Mar 18 '14 at 18:36
  • It is most likely when you cast type like char to int etc. Its usually caused by a bad byte signature in your primitive types like int and char. Optimization changes the memory allotment for the types, and causes problems. Try memcpy / memmove instead of casting. The limitations can be hardware specific. Avoid casting. – FlavorScape Jul 25 '14 at 17:18