Roald Baudoux

I have a very complex patcher using many buffers, players, effects, subpatchers, bpatchers, poly~, several controllers, etc. It's running under Max 6.0.8. It crashes sometimes when I start the audio, but not always and I can't figure out why. Last time I asked official support about this it appeared that my patcher was too complex to get help.

I really can't find the cause of these crashes. However it seems that the crashing thread is always the one with the biggest number (34) and it always looks like this :

0 libSystem.B.dylib     0xffff0820 __memcpy + 128

1 com.cycling74.in~     0x3eabc569 sin_perform64 + 46

2 com.cycling74.MaxAudioAPI     0x1ad7e792 dspchain_tick + 314

3 com.cycling74.MaxAudioAPI     0x1ad87baa plugrunner_tick + 99

4 com.cycling74.MaxAudioAPI     0x1ad87ff9 plugrunner_process + 157

5 com.cycling74.MaxAudioAPI     0x1ad9f6fd patchernode_process + 217

6 com.cycling74.MaxAudioAPI     0x1ad9be24 mixerengine_process_fun + 85

7 com.cycling74.MaxAudioAPI     0x1ad9be90 mixerengine_process_parallel_workerproc + 17

8 com.cycling74.Max     0x00234767 multigraph_parallel_iterator_workerproc + 49

9 com.cycling74.Max     0x000e774e sysparallel_worker_execute + 49

10 com.cycling74.Max     0x000e7ca0 sysparallel_task_execute + 124

11 com.cycling74.Max     0x00234668 multigraph_parallel_iterator_execute + 68

12 com.cycling74.MaxAPI     0x03e6df20 multigraph_parallel_iterator_execute + 32

13 com.cycling74.MaxAudioAPI     0x1ada148d mixerengine_process + 67

14 com.cycling74.MaxAudioAPI     0x1ada1797 mixerengine_processiovector + 703

15 com.cycling74.MaxAudioAPI     0x1ad76ecd ad_process + 266

16 com.cycling74.ad_coreaudio     0x04c78207 adcoreaudio_callback + 185

17 com.cycling74.Max     0x002a4060 WrapperCallback::audioDeviceIOCallback(float const**, int, float**, int, int) + 64

18 com.cycling74.Max     0x00447dc1 juce::CoreAudioInternal::audioCallback(AudioBufferList const*, AudioBufferList*) + 183

19 com.cycling74.Max     0x004479ee juce::CoreAudioInternal::audioIOProc(unsigned long, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 31

20 com.apple.audio.CoreAudio     0x9a458028 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374

21 com.apple.audio.CoreAudio     0x9a457d8e IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370

22 com.apple.audio.CoreAudio     0x9a457b7e HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620

23 com.apple.audio.CoreAudio     0x9a454f40 HP_IOThread::WorkLoop() + 2506

24 com.apple.audio.CoreAudio     0x9a454571 HP_IOThread::ThreadEntry(HP_IOThread*) + 17

25 com.apple.audio.CoreAudio     0x9a454488 CAPThread::Entry(CAPThread*) + 140

26 libSystem.B.dylib     0x98378259 _pthread_start + 345

27 libSystem.B.dylib     0x983780de thread_start + 34

Thread 34 crashed with X86 Thread State (32-bit):

eax: 0xffff07a0 ebx: 0x00000080 ecx: 0x00000000 edx: 0xfffffc00

edi: 0xba836740 esi: 0x00000400 ebp: 0xec060708 esp: 0xec060700

ss: 0x00000023 efl: 0x00010246 eip: 0xffff0820 cs: 0x0000001b

ds: 0x00000023 es: 0x00000023 fs: 0x00000023 gs: 0x0000000f

1. Why is there a 32-bits thread althought I am running Max 6 ?

2. Could the "plugrunner" thing have anything to do with the vst~ object ?

I have a very complex patcher using many buffers, players, effects, subpatchers, bpatchers, poly~, several controllers, etc. It's running under Max 6.0.8. It crashes sometimes when I start the audio,  but not always and I can't figure out why. Last time I asked official support about this it appeared that my patcher was too complex to get help.

Thread 34 Crashed:
0   libSystem.B.dylib             	0xffff0820 __memcpy + 128
1   com.cycling74.in~             	0x3eabc569 sin_perform64 + 46
2   com.cycling74.MaxAudioAPI     	0x1ad7e792 dspchain_tick + 314
3   com.cycling74.MaxAudioAPI     	0x1ad87baa plugrunner_tick + 99
4   com.cycling74.MaxAudioAPI     	0x1ad87ff9 plugrunner_process + 157
5   com.cycling74.MaxAudioAPI     	0x1ad9f6fd patchernode_process + 217
6   com.cycling74.MaxAudioAPI     	0x1ad9be24 mixerengine_process_fun + 85
7   com.cycling74.MaxAudioAPI     	0x1ad9be90 mixerengine_process_parallel_workerproc + 17
8   com.cycling74.Max             	0x00234767 multigraph_parallel_iterator_workerproc + 49
9   com.cycling74.Max             	0x000e774e sysparallel_worker_execute + 49
10  com.cycling74.Max             	0x000e7ca0 sysparallel_task_execute + 124
11  com.cycling74.Max             	0x00234668 multigraph_parallel_iterator_execute + 68
12  com.cycling74.MaxAPI          	0x03e6df20 multigraph_parallel_iterator_execute + 32
13  com.cycling74.MaxAudioAPI     	0x1ada148d mixerengine_process + 67
14  com.cycling74.MaxAudioAPI     	0x1ada1797 mixerengine_processiovector + 703
15  com.cycling74.MaxAudioAPI     	0x1ad76ecd ad_process + 266
16  com.cycling74.ad_coreaudio    	0x04c78207 adcoreaudio_callback + 185
17  com.cycling74.Max             	0x002a4060 WrapperCallback::audioDeviceIOCallback(float const**, int, float**, int, int) + 64
18  com.cycling74.Max             	0x00447dc1 juce::CoreAudioInternal::audioCallback(AudioBufferList const*, AudioBufferList*) + 183
19  com.cycling74.Max             	0x004479ee juce::CoreAudioInternal::audioIOProc(unsigned long, AudioTimeStamp const*, AudioBufferList const*, AudioTimeStamp const*, AudioBufferList*, AudioTimeStamp const*, void*) + 31
20  com.apple.audio.CoreAudio     	0x9a458028 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374
21  com.apple.audio.CoreAudio     	0x9a457d8e IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370
22  com.apple.audio.CoreAudio     	0x9a457b7e HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620
23  com.apple.audio.CoreAudio     	0x9a454f40 HP_IOThread::WorkLoop() + 2506
24  com.apple.audio.CoreAudio     	0x9a454571 HP_IOThread::ThreadEntry(HP_IOThread*) + 17
25  com.apple.audio.CoreAudio     	0x9a454488 CAPThread::Entry(CAPThread*) + 140
26  libSystem.B.dylib             	0x98378259 _pthread_start + 345
27  libSystem.B.dylib             	0x983780de thread_start + 34

Thread 34 crashed with X86 Thread State (32-bit):
  eax: 0xffff07a0  ebx: 0x00000080  ecx: 0x00000000  edx: 0xfffffc00
  edi: 0xba836740  esi: 0x00000400  ebp: 0xec060708  esp: 0xec060700
   ss: 0x00000023  efl: 0x00010246  eip: 0xffff0820   cs: 0x0000001b
   ds: 0x00000023   es: 0x00000023   fs: 0x00000023   gs: 0x0000000f
  cr2: 0x00000000

Two questions about this :
1. Why is there a 32-bits thread althought I am running Max 6 ?
2. Could the "plugrunner" thing have anything to do with the vst~ object ?

can-this-part-of-a-crashlog-tell-anything-about-the-cause-of-crashes

This looks like the poly~ inside a poly~ crash.

Poly~ inside a poly~ is not yet supported in Max 6. We're working on fixing it for Max 6.1

Actually after reviewing the tickets for this I'll say that there are some times when nested poly~s will work ok, but we have a bit of work to do to get them to be more stable in Max 6.

Well thanks Andrew, this is annoying but at least I am happy to know why the patcher crashes.

Any insight about the delay before Max 6.1's release ?

But... ...wait ! I do not have any poly~ inside a poly~ !

However I notice that the patcher doesn't crash anymore if I remove a bpatcher from the circuit before activating the audio for the first time. I remove a bpatcher, I activate the audio, stop it, replace the bpatcher (command-Z) then re-activate the audio: the patcher doesn't crash anymore.

The fun part: this "solution" works whatever the bpatcher removed, even the one containing the most stupidly basic subpatch which does even not contain a single MSP object, like the one copied below. But if I do not activate the audio prior to replace the removed bpatcher I have a crash !

Seems like a bug to me. Maybe I'll create a bogus bpatcher and remove it by script automatically to solve the problem for now but it's a bit twisted isn't it ?

How could a 32-bits application handle audio signals coded on 64 bits ?

If you have another way of reproducing this crash please send it all in to support. I'm not able to figure it out from the pasted code

Andrew I can send the whole crashlog to you but the patcher loads lots of bpatchers and poly~. What do I send to you ?

If you can isolate the crash somewhat that would be cool. Maybe you can't? Just send it all in but please give us some instructions

OK. Could you please remind me of the messages to send to Max to get a list of all the subpatchers and externals a patcher is using ?

By the way I notice that over the 34 threads more than 20 threads are linked to Java altough I use almost no Java, just mxj local I think. How is it possible ?

Make a project out of it and consolidate it , or take a snapshot.

because processing has absolutely nothing to do with the signal resolution.

16 bit processors can handle 128 bit numbers, and the other way round.

because processing has absolutely nothing to do with the signal resolution.
16 bit processors can handle 128 bit numbers, and the other way round.

I guess you're confusing the signal resolution used by Max to represent signals with the instruction set used by the application itself. See 

http://en.wikipedia.org/wiki/Analog-to-digital_converter#Resolution

http://en.wikipedia.org/wiki/Instruction_set#Instruction_length

I guess you're confusing the signal resolution used by Max to represent signals with the instruction set used by the application itself. See http://en.wikipedia.org/wiki/Analog-to-digital_converter#Resolution and http://en.wikipedia.org/wiki/Instruction_set#Instruction_length for a better explanation.

Can this part of a crashlog tell anything about the cause of crashes ?