jit.catch~ crashes Max 4.6 very often


    Jul 18 2008 | 4:27 pm
    (Max 4.6, Jitter 1.6.3, Macbook Pro 2x2.4GHz)
    I have a sprawling patch that uses one jit.catch~ object @mode 2. About 75% of the time, Max crashes when I open the patch. According to the crash logs (bottom of this post) the last operation in the crashed thread is always "max_jit_catch_perform + 451". If I remove jit.catch~ the crashes stop.
    The patch is full of colls, abstractions, etc, so I haven't posted it. (I know that's lame, but I tried to strip it to a postable form and I couldn't get it to crash.) It won't crash on my friend's machine (4.5), but will crash on my other machine with 4.6.
    In my startup sequence, colls are loaded and rendering windows are built, then a few seconds later audio turns on, then a few seconds later the gl render bangs start. (There's one sfplay~ but no files are triggered during startup.) The crashes happen when the gl chain gets banged. It is driving a jit.gl.graph object, using the undocumented @line_width option to make a thicker stroke, but that doesn't seem to matter. If it survives startup, everything renders fine.
    Besides startup, Max often crashes when I reinstantiate the jit.catch~ by adding new arguments.
    This is getting frustrating, and the gl oscilloscope looks so good that I don't want to "let go" of my jit.catch~!
    -Zach
    ------------------
    section of crashlog:
    ------------------
    Exception: EXC_BAD_ACCESS (0x0001)
    Codes: KERN_INVALID_ADDRESS (0x0001) at 0x6d49d118
    Thread 23 Crashed:
    0 com.cycling74.jit.catch~ 0x62720cbc max_jit_catch_perform + 451
    1 com.cycling74.MaxAudioAPI 0x01da6b0f dspchain_tick + 83 (d_ugen.c:228)
    2 com.cycling74.MaxAudioAPI 0x01da5551 ad_process + 392 (ad.c:1850)
    3 com.cycling74.ad_coreaudio 0x15d504c0 coreaudio_twodevice_ioproc + 558
    4 com.apple.audio.CoreAudio 0x91477872 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 240
    5 com.apple.audio.CoreAudio 0x91476d9a IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 274
    6 com.apple.audio.CoreAudio 0x91476b21 HP_IOThread::PerformIO(AudioTimeStamp const&) + 1299
    7 com.apple.audio.CoreAudio 0x91474f49 HP_IOThread::WorkLoop() + 953
    8 com.apple.audio.CoreAudio 0x91474b8b HP_IOThread::ThreadEntry(HP_IOThread*) + 17
    9 com.apple.audio.CoreAudio 0x91469171 CAPThread::Entry(CAPThread*) + 93
    10 libSystem.B.dylib 0x90024227 _pthread_body + 84

    • Jul 19 2008 | 5:53 am
      (Replying to my own post)
      I made a workaround, based on jit.poke~ and the stroke method of jit.gl.sketch (expertly explained in the "Twineball" patch from Jitter Recipes: Book 2.
      It produces no crashes in the context of my patch.
      For future searchers: The following patch is a gl oscilloscope with adjustable stroke width. The results are similar to the jit.gl.graph help patch, but achieved through different means. Enjoy.
      -Zach
      max v2;