Can this part of a crashlog tell anything about the cause of crashes ?
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 0×00234767 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 0×00234668 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 0×98378259 _pthread_start + 345
27 libSystem.B.dylib 0x983780de thread_start + 34
Thread 34 crashed with X86 Thread State (32-bit):
eax: 0xffff07a0 ebx: 0×00000080 ecx: 0×00000000 edx: 0xfffffc00
edi: 0xba836740 esi: 0×00000400 ebp: 0xec060708 esp: 0xec060700
ss: 0×00000023 efl: 0×00010246 eip: 0xffff0820 cs: 0x0000001b
ds: 0×00000023 es: 0×00000023 fs: 0×00000023 gs: 0x0000000f
cr2: 0×00000000
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.
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
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
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 ?
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
How could a 32-bits application handle audio signals coded on 64 bits ?
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
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
Thanks!
-A
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.
Cheers
-A
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
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