pfft~ in poly~ crashes?


    Nov 05 2011 | 5:43 pm
    I have a very weird and bad crash in a big complicate patch, apparently due to poly's out~. The structure is like this: I have a poly~, having a subpatch containing itsself a poly~ inside. Inside this second poly I have all standard MSP treatments (no weird object), but here's the "funny" part: one of those object inside this second poly~ is a [pfft~ gizmo_loadme]. As soon as I get rid of it, I have no more crashes. As soon as I put it back, if I try to run two "run" two instances of the first poly, rainbow-wheel for some seconds, and crash.
    I was wondering if there's somebody who had the same issue, or a similar one, and I tried to reproduce the thing. I built a very simple poly~ in poly~ situation (with a play~ in the inner poly~), and I had a bad crash at saving time. So I'm puzzled. Of course, I completed the full smaller example, and everything worked in the simple one. Is there maybe some known incompatibility between gismo~ and other stuff?
    I'm on Max 5.1.9, but I tried in Max 6 and I still have crashes. The snippet of a common bug report is:
    Process: MaxMSP [17023] Path: /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP Identifier: MaxMSP Version: ??? (???) Code Type: X86 (Native) Parent Process: launchd [189]
    Date/Time: 2011-11-05 18:13:23.508 +0100 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6
    Interval Since Last Report: 2559679 sec Crashes Since Last Report: 86 Per-App Crashes Since Last Report: 2 Anonymous UUID: 422A41C2-C578-4B2C-8833-5181E491657E
    Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000200 Crashed Thread: 33
    ====
    Thread 33 Crashed: 0 com.cycling74.out~ 0x34171ac1 sout_perform2 + 62 1 com.cycling74.MaxAudioAPI 0x027ca2ec dspchain_tick + 90 2 com.cycling74.poly~ 0x3241e2f8 poly_run + 401 3 com.cycling74.poly~ 0x32420a69 poly_processnormal + 216 4 com.cycling74.poly~ 0x32420e8a poly_perform + 146 5 com.cycling74.MaxAudioAPI 0x027ca2ec dspchain_tick + 90 6 com.cycling74.poly~ 0x3241e158 poly_workerproc + 141 7 com.cycling74.MaxMSP 0x000fafbb sysparallel_worker_execute + 37 8 com.cycling74.MaxMSP 0x000fb518 sysparallel_threadproc(_sysparallel_thread*) + 90 9 com.cycling74.MaxMSP 0x00065ce8 systhread_threadproc(void*) + 60 10 libSystem.B.dylib 0x971bd259 _pthread_start + 345 11 libSystem.B.dylib 0x971bd0de thread_start + 34

    • Nov 26 2011 | 11:02 am
      Hi Daniel, I a very big patch I also have a crash with a poly~loading a Gizmo~. The problem for me seems to be related to the poly's input.
      There is something weird, I have a mono version of my patch who works very well and the stereo version crash when I start the audio chain.
      Do someone know a way to fix this issue? Philippe.
      Process: Max [1428] Path: /Applications/Max6/Max.app/Contents/MacOS/Max Identifier: com.cycling74.MaxMSP Version: 6.0.1 (50928) (6.0.1) Code Type: X86 (Native) Parent Process: launchd [169]
      Date/Time: 2011-11-26 11:51:31.114 +0100 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6
      Interval Since Last Report: 177422 sec Crashes Since Last Report: 72 Per-App Interval Since Last Report: 152481 sec Per-App Crashes Since Last Report: 29 Anonymous UUID: C3F57E6F-1A05-4E92-8E4F-98505D2E87BC
      Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 29
      Thread 29 Crashed: 0 libSystem.B.dylib 0xffff08a0 __memcpy + 256 1 com.cycling74.in~ 0x38685835 sin_perform64 + 46 2 com.cycling74.MaxAudioAPI 0x179cb0d3 dspchain_tick + 323 3 com.cycling74.MaxAudioAPI 0x179d41da plugrunner_tick + 96 4 com.cycling74.MaxAudioAPI 0x179d455d plugrunner_process + 125 5 com.cycling74.MaxAudioAPI 0x179eb2c3 patchernode_process + 217 6 com.cycling74.MaxMSP 0x000b3853 object_method + 963 7 com.cycling74.MaxAPI 0x01e216eb object_method + 139 8 com.cycling74.MaxAudioAPI 0x179e7d91 mixerengine_process_fun + 91 9 com.cycling74.MaxAudioAPI 0x179e7dd7 mixerengine_process_parallel_workerproc + 17 10 com.cycling74.MaxMSP 0x00238a48 multigraph_parallel_iterator_workerproc + 49 11 com.cycling74.MaxMSP 0x000f2c7a sysparallel_worker_execute + 49 12 com.cycling74.MaxMSP 0x000f31cc sysparallel_task_execute + 124 13 com.cycling74.MaxMSP 0x00238949 multigraph_parallel_iterator_execute + 68 14 com.cycling74.MaxAPI 0x01e35150 multigraph_parallel_iterator_execute + 32 15 com.cycling74.MaxAudioAPI 0x179ed054 mixerengine_process + 67 16 com.cycling74.MaxAudioAPI 0x179ed365 mixerengine_processiovector + 710 17 com.cycling74.MaxAudioAPI 0x179c400b ad_process + 218 18 com.cycling74.ad_coreaudio 0x18edfa47 coreaudio_ioproc + 369 19 com.apple.audio.CoreAudio 0x97942028 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374 20 com.apple.audio.CoreAudio 0x97941d8e IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370 21 com.apple.audio.CoreAudio 0x97941b7e HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620 22 com.apple.audio.CoreAudio 0x9793ef40 HP_IOThread::WorkLoop() + 2506 23 com.apple.audio.CoreAudio 0x9793e571 HP_IOThread::ThreadEntry(HP_IOThread*) + 17 24 com.apple.audio.CoreAudio 0x9793e488 CAPThread::Entry(CAPThread*) + 140 25 libSystem.B.dylib 0x90e63259 _pthread_start + 345 26 libSystem.B.dylib 0x90e630de thread_start + 34
    • Nov 27 2011 | 2:32 pm
      Hi Daniel, Finally, after some modifications in the patch's structure, without modifications in the poly~itself... The crashreport changed and is now really close to yours. Philippe.
      Thread 31 Crashed: 0 com.cycling74.out~ 0x370fb7c8 sout_perform64 + 21 1 com.cycling74.MaxAudioAPI 0x179ce0d3 dspchain_tick + 323 2 com.cycling74.poly~ 0x370ec145 poly_workerproc + 141 3 com.cycling74.MaxMSP 0x000f2c7a sysparallel_worker_execute + 49 4 com.cycling74.MaxMSP 0x000f2bf3 sysparallel_threadproc + 111 5 com.cycling74.MaxMSP 0x0006c17c systhread_threadproc + 54 6 libSystem.B.dylib 0x90e63259 _pthread_start + 345 7 libSystem.B.dylib 0x90e630de thread_start + 34
    • Dec 12 2011 | 2:52 pm
      I have the same problem - pfft~ works outside a poly~, but crashes when I put it inside a poly~. For me this problem only comes with Max 6, not with Max 5.
      I don't have a solution, but found something else: if I first use a patch with the pfft~ *not* in a poly~, then I can then use it in a poly~ without the crash, until I restart Max, and then the problem returns.
      This means that a temporary fix is to put one copy of the pfft~ on the top level of the patch - then all the others inside poly~s seem to work without crashing.
      I'd be interested to know of any proper solution.
      John
      Thread 32 Crashed:: com.apple.audio.IOThread.client 0 com.cycling74.out~ 0x0bff87c8 sout_perform64 + 21 1 com.cycling74.MaxAudioAPI 0x0a04f0d3 dspchain_tick + 323 2 com.cycling74.poly~ 0x0f76f0aa poly_run + 382 3 com.cycling74.poly~ 0x0f76e20c poly_processnormal + 283 4 com.cycling74.poly~ 0x0f76fabd poly_perform + 137 5 com.cycling74.poly~ 0x0f76fb47 poly_perform64 + 103 6 com.cycling74.MaxAudioAPI 0x0a04f0d3 dspchain_tick + 323 7 com.cycling74.MaxAudioAPI 0x0a0581da plugrunner_tick + 96 8 com.cycling74.MaxAudioAPI 0x0a05855d plugrunner_process + 125 9 com.cycling74.MaxAudioAPI 0x0a06f2c3 patchernode_process + 217 10 com.cycling74.MaxMSP 0x000b3853 object_method + 963 11 com.cycling74.MaxAPI 0x032fe6eb object_method + 139 12 com.cycling74.MaxAudioAPI 0x0a06bd91 mixerengine_process_fun + 91 13 com.cycling74.MaxMSP 0x0005fe7c linklist_funall_imp + 96 14 com.cycling74.MaxMSP 0x0005ff20 linklist_funall + 39 15 com.cycling74.MaxAPI 0x032f614d linklist_funall + 61 16 com.cycling74.MaxAudioAPI 0x0a071082 mixerengine_process + 113 17 com.cycling74.MaxAudioAPI 0x0a071365 mixerengine_processiovector + 710 18 com.cycling74.MaxAudioAPI 0x0a04800b ad_process + 218 19 com.cycling74.ad_coreaudio 0x03df8a47 coreaudio_ioproc + 369 20 com.apple.audio.CoreAudio 0x9b7623cd HALC_ProxyIOContext::IOWorkLoop() + 2535 21 com.apple.audio.CoreAudio 0x9b761926 HALC_ProxyIOContext::IOThreadEntry(void*) + 136 22 com.apple.audio.CoreAudio 0x9b761898 __HALC_ProxyIOContext_block_invoke_6 + 20 23 com.apple.audio.CoreAudio 0x9b76181d HALB_IOThread::Entry(void*) + 69 24 libsystem_c.dylib 0x9c78fed9 _pthread_start + 335 25 libsystem_c.dylib 0x9c7936de thread_start + 34
    • May 10 2012 | 9:57 am
      Thanks Phillippe, Thanks John,
      it's been a while I haven't checked this thread.
      Does anybody know if the problem has been focused and solved with 6.0.5? I'm still in Max 5 and I could not solve the issue, which is quite frustrating...
      Daniele
    • May 10 2012 | 10:04 am
      John, your method does not seem to work for me. I've put an instance of the gizmo_loadme inside a pfft in the main level, and yet it crashes again:
      Thread 6 Crashed: 0 com.cycling74.out~ 0x3a8e8ac1 sout_perform2 + 62 1 com.cycling74.MaxAudioAPI 0x151942ec dspchain_tick + 90 2 com.cycling74.poly~ 0x380502f8 poly_run + 401 3 com.cycling74.poly~ 0x38052a69 poly_processnormal + 216 4 com.cycling74.poly~ 0x38052e8a poly_perform + 146 5 com.cycling74.MaxAudioAPI 0x151942ec dspchain_tick + 90 6 com.cycling74.poly~ 0x380502f8 poly_run + 401 7 com.cycling74.poly~ 0x38052a69 poly_processnormal + 216 8 com.cycling74.poly~ 0x38052e8a poly_perform + 146 9 com.cycling74.MaxAudioAPI 0x151942ec dspchain_tick + 90 10 com.cycling74.MaxAudioAPI 0x15192d1c ad_process + 470 11 com.cycling74.ad_coreaudio 0x1c7efe2a coreaudio_ioproc + 378 12 com.apple.audio.CoreAudio 0x99bb3028 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374 13 com.apple.audio.CoreAudio 0x99bb2d8e IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370 14 com.apple.audio.CoreAudio 0x99bb2b7e HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620 15 com.apple.audio.CoreAudio 0x99baff40 HP_IOThread::WorkLoop() + 2506 16 com.apple.audio.CoreAudio 0x99baf571 HP_IOThread::ThreadEntry(HP_IOThread*) + 17 17 com.apple.audio.CoreAudio 0x99baf488 CAPThread::Entry(CAPThread*) + 140 18 libSystem.B.dylib 0x9a1a4259 _pthread_start + 345 19 libSystem.B.dylib 0x9a1a40de thread_start + 34