Forums MaxMSP

reson~ appears to be crashing


Chris Rolfe

Chris Rolfe
Mar 16, 2009 at 9:29pm

reson~ appears to be crashing

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 0×0000000017204000
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

—–

#42890

Emmanuel Jourdan

Emmanuel Jourdan
Mar 17, 2009 at 2:07am

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

Thanks,

#153534

Chris Rolfe

Chris Rolfe
Mar 17, 2009 at 6:31pm

Vector size is 4096.

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.

#153535

You must be logged in to reply to this topic.

Forums MaxMSP