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

Roald Baudoux's icon

Hello,

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 :

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 ?

Thank you in advance.

Andrew Pask's icon

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

Cheers

Andrew

Andrew Pask's icon

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.

-A

Roald Baudoux's icon

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 ?

Roald Baudoux's icon

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 !

Max Patch
Copy patch and select New From Clipboard in Max.

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 ?

$Adam's icon

Hi,

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

Because Max is a 32-bit application.

Cheers,
Ádám

Roald Baudoux's icon

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

Andrew Pask's icon

Hey Roald,

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

Cheers

Roald Baudoux's icon

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

Andrew Pask's icon

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

Thanks!

-A

Roald Baudoux's icon

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 ?

Andrew Pask's icon

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

Cheers

-A

Roman Thilenius's icon

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

-110

$Adam's icon

Hi Roald,

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.

Hope this helps,
Ádám