Cycling 74 » Topic: pfft~ in poly~ crashes? http://cycling74.com/forums/topic/pfft-in-poly-crashes/feed Wed, 19 Jun 2013 16:54:05 +0000 http://bbpress.org/?v=2.2.4 http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-59823 <![CDATA[pfft~ in poly~ crashes?]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-59823 Sat, 05 Nov 2011 17:43:52 +0000 danieleghisi I have a very weird and bad crash in a big complicate patch, apparently due to poly’s out~.
The structure is like this: I have a poly~, having a subpatch containing itsself a poly~ inside. Inside this second poly I have all standard MSP treatments (no weird object), but here’s the “funny” part: one of those object inside this second poly~ is a [pfft~ gizmo_loadme]. As soon as I get rid of it, I have no more crashes.
As soon as I put it back, if I try to run two “run” two instances of the first poly, rainbow-wheel for some seconds, and crash.

I was wondering if there’s somebody who had the same issue, or a similar one, and I tried to reproduce the thing.
I built a very simple poly~ in poly~ situation (with a play~ in the inner poly~), and I had a bad crash at saving time. So I’m puzzled. Of course, I completed the full smaller example, and everything worked in the simple one.
Is there maybe some known incompatibility between gismo~ and other stuff?

I’m on Max 5.1.9, but I tried in Max 6 and I still have crashes.
The snippet of a common bug report is:

Process: MaxMSP [17023]
Path: /Applications/Max5/MaxMSP.app/Contents/MacOS/MaxMSP
Identifier: MaxMSP
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: launchd [189]

Date/Time: 2011-11-05 18:13:23.508 +0100
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6

Interval Since Last Report: 2559679 sec
Crashes Since Last Report: 86
Per-App Crashes Since Last Report: 2
Anonymous UUID: 422A41C2-C578-4B2C-8833-5181E491657E

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0×0000000000000200
Crashed Thread: 33

====

Thread 33 Crashed:
0 com.cycling74.out~ 0x34171ac1 sout_perform2 + 62
1 com.cycling74.MaxAudioAPI 0x027ca2ec dspchain_tick + 90
2 com.cycling74.poly~ 0x3241e2f8 poly_run + 401
3 com.cycling74.poly~ 0x32420a69 poly_processnormal + 216
4 com.cycling74.poly~ 0x32420e8a poly_perform + 146
5 com.cycling74.MaxAudioAPI 0x027ca2ec dspchain_tick + 90
6 com.cycling74.poly~ 0x3241e158 poly_workerproc + 141
7 com.cycling74.MaxMSP 0x000fafbb sysparallel_worker_execute + 37
8 com.cycling74.MaxMSP 0x000fb518 sysparallel_threadproc(_sysparallel_thread*) + 90
9 com.cycling74.MaxMSP 0x00065ce8 systhread_threadproc(void*) + 60
10 libSystem.B.dylib 0x971bd259 _pthread_start + 345
11 libSystem.B.dylib 0x971bd0de thread_start + 34

]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215288 <![CDATA[Re: pfft~ in poly~ crashes?]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215288 Sat, 26 Nov 2011 11:02:51 +0000 Philippe OLLIVIER Hi Daniel,
I a very big patch I also have a crash with a poly~loading a Gizmo~.
The problem for me seems to be related to the poly’s input.

There is something weird, I have a mono version of my patch who works very well and the stereo version crash when I start the audio chain.

Do someone know a way to fix this issue?
Philippe.

Process: Max [1428]
Path: /Applications/Max6/Max.app/Contents/MacOS/Max
Identifier: com.cycling74.MaxMSP
Version: 6.0.1 (50928) (6.0.1)
Code Type: X86 (Native)
Parent Process: launchd [169]

Date/Time: 2011-11-26 11:51:31.114 +0100
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6

Interval Since Last Report: 177422 sec
Crashes Since Last Report: 72
Per-App Interval Since Last Report: 152481 sec
Per-App Crashes Since Last Report: 29
Anonymous UUID: C3F57E6F-1A05-4E92-8E4F-98505D2E87BC

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0×0000000000000000
Crashed Thread: 29

Thread 29 Crashed:
0 libSystem.B.dylib 0xffff08a0 __memcpy + 256
1 com.cycling74.in~ 0×38685835 sin_perform64 + 46
2 com.cycling74.MaxAudioAPI 0x179cb0d3 dspchain_tick + 323
3 com.cycling74.MaxAudioAPI 0x179d41da plugrunner_tick + 96
4 com.cycling74.MaxAudioAPI 0x179d455d plugrunner_process + 125
5 com.cycling74.MaxAudioAPI 0x179eb2c3 patchernode_process + 217
6 com.cycling74.MaxMSP 0x000b3853 object_method + 963
7 com.cycling74.MaxAPI 0x01e216eb object_method + 139
8 com.cycling74.MaxAudioAPI 0x179e7d91 mixerengine_process_fun + 91
9 com.cycling74.MaxAudioAPI 0x179e7dd7 mixerengine_process_parallel_workerproc + 17
10 com.cycling74.MaxMSP 0x00238a48 multigraph_parallel_iterator_workerproc + 49
11 com.cycling74.MaxMSP 0x000f2c7a sysparallel_worker_execute + 49
12 com.cycling74.MaxMSP 0x000f31cc sysparallel_task_execute + 124
13 com.cycling74.MaxMSP 0×00238949 multigraph_parallel_iterator_execute + 68
14 com.cycling74.MaxAPI 0x01e35150 multigraph_parallel_iterator_execute + 32
15 com.cycling74.MaxAudioAPI 0x179ed054 mixerengine_process + 67
16 com.cycling74.MaxAudioAPI 0x179ed365 mixerengine_processiovector + 710
17 com.cycling74.MaxAudioAPI 0x179c400b ad_process + 218
18 com.cycling74.ad_coreaudio 0x18edfa47 coreaudio_ioproc + 369
19 com.apple.audio.CoreAudio 0×97942028 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374
20 com.apple.audio.CoreAudio 0x97941d8e IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370
21 com.apple.audio.CoreAudio 0x97941b7e HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620
22 com.apple.audio.CoreAudio 0x9793ef40 HP_IOThread::WorkLoop() + 2506
23 com.apple.audio.CoreAudio 0x9793e571 HP_IOThread::ThreadEntry(HP_IOThread*) + 17
24 com.apple.audio.CoreAudio 0x9793e488 CAPThread::Entry(CAPThread*) + 140
25 libSystem.B.dylib 0x90e63259 _pthread_start + 345
26 libSystem.B.dylib 0x90e630de thread_start + 34

]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215289 <![CDATA[Re: pfft~ in poly~ crashes?]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215289 Sun, 27 Nov 2011 14:32:04 +0000 Philippe OLLIVIER Hi Daniel,
Finally, after some modifications in the patch’s structure, without modifications in the poly~itself… The crashreport changed and is now really close to yours.
Philippe.

Thread 31 Crashed:
0 com.cycling74.out~ 0x370fb7c8 sout_perform64 + 21
1 com.cycling74.MaxAudioAPI 0x179ce0d3 dspchain_tick + 323
2 com.cycling74.poly~ 0x370ec145 poly_workerproc + 141
3 com.cycling74.MaxMSP 0x000f2c7a sysparallel_worker_execute + 49
4 com.cycling74.MaxMSP 0x000f2bf3 sysparallel_threadproc + 111
5 com.cycling74.MaxMSP 0x0006c17c systhread_threadproc + 54
6 libSystem.B.dylib 0x90e63259 _pthread_start + 345
7 libSystem.B.dylib 0x90e630de thread_start + 34

]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215290 <![CDATA[Re: pfft~ in poly~ crashes?]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215290 Mon, 12 Dec 2011 14:52:09 +0000 John Croft I have the same problem – pfft~ works outside a poly~, but crashes when I put it inside a poly~. For me this problem only comes with Max 6, not with Max 5.

I don’t have a solution, but found something else: if I first use a patch with the pfft~ *not* in a poly~, then I can then use it in a poly~ without the crash, until I restart Max, and then the problem returns.

This means that a temporary fix is to put one copy of the pfft~ on the top level of the patch – then all the others inside poly~s seem to work without crashing.

I’d be interested to know of any proper solution.

John

Thread 32 Crashed:: com.apple.audio.IOThread.client
0 com.cycling74.out~ 0x0bff87c8 sout_perform64 + 21
1 com.cycling74.MaxAudioAPI 0x0a04f0d3 dspchain_tick + 323
2 com.cycling74.poly~ 0x0f76f0aa poly_run + 382
3 com.cycling74.poly~ 0x0f76e20c poly_processnormal + 283
4 com.cycling74.poly~ 0x0f76fabd poly_perform + 137
5 com.cycling74.poly~ 0x0f76fb47 poly_perform64 + 103
6 com.cycling74.MaxAudioAPI 0x0a04f0d3 dspchain_tick + 323
7 com.cycling74.MaxAudioAPI 0x0a0581da plugrunner_tick + 96
8 com.cycling74.MaxAudioAPI 0x0a05855d plugrunner_process + 125
9 com.cycling74.MaxAudioAPI 0x0a06f2c3 patchernode_process + 217
10 com.cycling74.MaxMSP 0x000b3853 object_method + 963
11 com.cycling74.MaxAPI 0x032fe6eb object_method + 139
12 com.cycling74.MaxAudioAPI 0x0a06bd91 mixerengine_process_fun + 91
13 com.cycling74.MaxMSP 0x0005fe7c linklist_funall_imp + 96
14 com.cycling74.MaxMSP 0x0005ff20 linklist_funall + 39
15 com.cycling74.MaxAPI 0x032f614d linklist_funall + 61
16 com.cycling74.MaxAudioAPI 0x0a071082 mixerengine_process + 113
17 com.cycling74.MaxAudioAPI 0x0a071365 mixerengine_processiovector + 710
18 com.cycling74.MaxAudioAPI 0x0a04800b ad_process + 218
19 com.cycling74.ad_coreaudio 0x03df8a47 coreaudio_ioproc + 369
20 com.apple.audio.CoreAudio 0x9b7623cd HALC_ProxyIOContext::IOWorkLoop() + 2535
21 com.apple.audio.CoreAudio 0x9b761926 HALC_ProxyIOContext::IOThreadEntry(void*) + 136
22 com.apple.audio.CoreAudio 0x9b761898 __HALC_ProxyIOContext_block_invoke_6 + 20
23 com.apple.audio.CoreAudio 0x9b76181d HALB_IOThread::Entry(void*) + 69
24 libsystem_c.dylib 0x9c78fed9 _pthread_start + 335
25 libsystem_c.dylib 0x9c7936de thread_start + 34

]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215291 <![CDATA[Re: pfft~ in poly~ crashes?]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215291 Thu, 10 May 2012 09:57:20 +0000 danieleghisi Thanks Phillippe, Thanks John,

it’s been a while I haven’t checked this thread.

Does anybody know if the problem has been focused and solved with 6.0.5?
I’m still in Max 5 and I could not solve the issue, which is quite frustrating…

Daniele

]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215292 <![CDATA[Re: pfft~ in poly~ crashes?]]> http://cycling74.com/forums/topic/pfft-in-poly-crashes/#post-215292 Thu, 10 May 2012 10:04:46 +0000 danieleghisi John, your method does not seem to work for me.
I’ve put an instance of the gizmo_loadme inside a pfft in the main level, and yet it crashes again:

Thread 6 Crashed:
0 com.cycling74.out~ 0x3a8e8ac1 sout_perform2 + 62
1 com.cycling74.MaxAudioAPI 0x151942ec dspchain_tick + 90
2 com.cycling74.poly~ 0x380502f8 poly_run + 401
3 com.cycling74.poly~ 0x38052a69 poly_processnormal + 216
4 com.cycling74.poly~ 0x38052e8a poly_perform + 146
5 com.cycling74.MaxAudioAPI 0x151942ec dspchain_tick + 90
6 com.cycling74.poly~ 0x380502f8 poly_run + 401
7 com.cycling74.poly~ 0x38052a69 poly_processnormal + 216
8 com.cycling74.poly~ 0x38052e8a poly_perform + 146
9 com.cycling74.MaxAudioAPI 0x151942ec dspchain_tick + 90
10 com.cycling74.MaxAudioAPI 0x15192d1c ad_process + 470
11 com.cycling74.ad_coreaudio 0x1c7efe2a coreaudio_ioproc + 378
12 com.apple.audio.CoreAudio 0x99bb3028 HP_IOProc::Call(AudioTimeStamp const&, AudioTimeStamp const&, AudioBufferList const*, AudioTimeStamp const&, AudioBufferList*) + 374
13 com.apple.audio.CoreAudio 0x99bb2d8e IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 370
14 com.apple.audio.CoreAudio 0x99bb2b7e HP_IOThread::PerformIO(AudioTimeStamp const&, double) + 620
15 com.apple.audio.CoreAudio 0x99baff40 HP_IOThread::WorkLoop() + 2506
16 com.apple.audio.CoreAudio 0x99baf571 HP_IOThread::ThreadEntry(HP_IOThread*) + 17
17 com.apple.audio.CoreAudio 0x99baf488 CAPThread::Entry(CAPThread*) + 140
18 libSystem.B.dylib 0x9a1a4259 _pthread_start + 345
19 libSystem.B.dylib 0x9a1a40de thread_start + 34

]]>