Beachballing + Crashing: Help diagnosing

Bugs
1

Hello,

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)

Badnesses:

  1. 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%)
  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 [0]

<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
  1. 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 [0]

<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?

Questions:

  1. 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?
  2. 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.
2

Ok, the first of these (the beachballs) was because erroneous 0s were being sent to fl.interval~ every now and again, but I didn’t seem to be getting the nice timeout message in the status bar in my patch until I made something smaller to test.

3

Thanks for this - patches and steps to reproduce would help here.

You will beach ball for several seconds if you send interval a zero -that may tighten up later - it’s more necessary to address this now, because NRT requires a different or more customisable approach.

I’ve seen the timeout message not appear. The dynamic cast failing seems impossible, so probably the call is happening when the pointer has been released. I will try to protect against that, but code to test with would help me be confident In my success.

4

I will endeavour to make reproducible cases of each. Seems like the frommax~ dynamic cast death is more prone to happen in situations where I’ve caused a timeout, but that’s purely in the realm of feelings, rather than neutral fact.