I’m going to need some help unravelling this before I can turn it into a proper bug report, including determining if three bits of weirdness are related. I’m now getting a crash when Max tries to recover my work in progress, but I’m not sure how to preserve this for posterity, beyond just grabbing the report.
I’m using a build from commit d12b329 (just before threading)
- Weird beachballing on the audio thread: I added a subpatch to my FL graph, using the cepstral envelope stuff @a.harker shared on the Flucoma forum. When I connected stuff to the outlet of this suppatcher, I kept getting freezes in the audio and beach balls (although the reported CPU seemed to be steady at 2%)
- Then I foolishly popped
fl.tomax~on the outlet to see if I could see anything bad, and got a crash thus:
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000208 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler  <snip> Thread 51 Crashed:: com.apple.audio.IOThread.client 0 AHarker.fl-tomax- 0x00000001220c284b FrameLib_LocalAllocator::alloc(unsigned long) + 27 1 AHarker.fl-tomax- 0x00000001220ae89f FrameLib_MaxClass_ToMax::ToHostProxy::sendToHost(unsigned long, unsigned long, double const*, unsigned long) + 63 2 AHarker.fl-tomax- 0x00000001220ae05d FrameLib_ToHost::process() + 109 3 AHarker.fl-perblock- 0x000000012222f9d8 FrameLib_ProcessingQueue::add(FrameLib_DSP*) + 2776 4 AHarker.fl-perblock- 0x000000012223028e FrameLib_DSP::blockUpdate(double const* const*, double**, unsigned long) + 350 5 AHarker.fl-perblock- 0x000000012222603c FrameLib_Expand<FrameLib_PerBlock>::blockUpdate(double const* const*, double**, unsigned long) + 1116
- Now when Max tries to recover my patch
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00000000fffffff8 Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler  <snip> Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread 0 libc++abi.dylib 0xa01cd0c0 __dynamic_cast + 20 1 AHarker.fl-frommax- 0x179e4016 FrameLib_MaxGlobals::ErrorNotifier::errorReport(FrameLib_MaxGlobals*) + 150 2 com.cycling74.Max 0x000fe11e sched_dequeue + 238
Does that look like Framelib is trying to tell me something, but crashing in the process of doing so because
dynamic_cast is failing?
- Is there a way of grabbing the offending temporary patch that Max is trying to load, so that it can be probed further, whilst also allowing me to get on with some work?
- Is the badness with audio beachballing likely to be related to the subpatchery-ness of the network in question, or is that a red herring? Happy enough to try and reduce this to a minimal example.