Chris Rolfe

A complex patcher with 4-5 C externals, and 1 java external is crashing, apparently in the reson~ perform routine.

Is this necessarily a problem with reson~ (in which case, I'll avoid using the object), or could the crash be coincidental (perhaps a bomb in the private externals)?

Model: MacBookPro3,1, Intel Core 2 Duo, 2.4 GHz, 2 GB

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000017204000

0 com.cycling74.reson~ 0x1b8ec8b3 reson_perform_unroll + 744

1 com.cycling74.MaxAudioAPI 0x131fe9d1 dspchain_tick + 93

2 com.cycling74.MaxAudioAPI 0x131fd2d5 ad_process + 457

3 com.cycling74.ad_coreaudio 0x17d4960b coreaudio_twodevice_ioproc + 537

4 com.apple.audio.CoreAudio 0x9359d15b HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 319

5 com.apple.audio.CoreAudio 0x9359ce4c IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 274

6 com.apple.audio.CoreAudio 0x9359cd28 HP_IOThread::PerformIO(AudioTimeStamp const&) + 1246

7 com.apple.audio.CoreAudio 0x9359b103 HP_IOThread::WorkLoop() + 1239

8 com.apple.audio.CoreAudio 0x9359ac27 HP_IOThread::ThreadEntry(HP_IOThread*) + 17

9 com.apple.audio.CoreAudio 0x9358b464 CAPThread::Entry(CAPThread*) + 96

10 libSystem.B.dylib 0x914b6095 _pthread_start + 321

11 libSystem.B.dylib 0x914b5f52 thread_start + 34

A complex patcher with 4-5 C externals, and 1 java external is crashing, apparently in the reson~ perform routine. 

Is this necessarily a problem with reson~ (in which case, I'll avoid using the object), or could the crash be coincidental (perhaps a bomb in the private externals)? 

---------
Model: MacBookPro3,1, Intel Core 2 Duo, 2.4 GHz, 2 GB
OS Version: 10.5.6 
Max Version:   5.0.6 (37726) (5.0.6)

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000017204000
Crashed Thread:  19

Thread 19 Crashed:
0   com.cycling74.reson~            0x1b8ec8b3 reson_perform_unroll + 744
1   com.cycling74.MaxAudioAPI       0x131fe9d1 dspchain_tick + 93
2   com.cycling74.MaxAudioAPI       0x131fd2d5 ad_process + 457
3   com.cycling74.ad_coreaudio      0x17d4960b coreaudio_twodevice_ioproc + 537
4   com.apple.audio.CoreAudio       0x9359d15b HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 319
5   com.apple.audio.CoreAudio       0x9359ce4c IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 274
6   com.apple.audio.CoreAudio       0x9359cd28 HP_IOThread::PerformIO(AudioTimeStamp const&) + 1246
7   com.apple.audio.CoreAudio       0x9359b103 HP_IOThread::WorkLoop() + 1239
8   com.apple.audio.CoreAudio       0x9359ac27 HP_IOThread::ThreadEntry(HP_IOThread*) + 17
9   com.apple.audio.CoreAudio       0x9358b464 CAPThread::Entry(CAPThread*) + 96
10  libSystem.B.dylib               0x914b6095 _pthread_start + 321
11  libSystem.B.dylib               0x914b5f52 thread_start + 34

reson-appears-to-be-crashing

Could you provide a patch to reproduce? What is your vector size?

Sorry, but I can't find steps to recreate -- it's a complex application that's crashing once or twice a day, after 1-20 minutes, but not reliably. The crash, though, occurs consistently in reson_perform_unroll + 744.

I isolated the subpatcher containing the reson filters, but couldn't recreate the crash after 30 minutes. But similarly, I've been running the application itself for 30 minutes now without a crash.

This is an application for a live event end of April, so it has to meet minimum requirements of stability. If I could assure myself the resons~ are indeed the source of the crash, I'd remove the reson filters from the app.

Any suggestions on how to troubleshoot this?

At this point, everyone's a suspect: my own externals, or maybe a problem with the current OS. 

I isolated the subpatcher containing the reson filters, but couldn't recreate the crash after 30 minutes. But similarly, I've been running the application itself for 30 minutes now without a crash. 

This is an application for a live event end of April, so it has to meet minimum requirements of stability. If I could assure myself the resons~ are indeed the source of the crash, I'd remove the reson filters from the app. 

Any suggestions on how to troubleshoot this? 

At this point, everyone's a suspect: my own externals, or maybe a problem with the current OS. 


reson~ appears to be crashing