Unity Crash On Play (Mac OSX x86_64)

[bsangston]

I have a very complicated procedural music patch that has been working fine in Unity, but after adding a small distortion object, it causes Unity to crash on play. I've isolated it to this particular patch (i.e. it works fine without it and no other changes), but all of the objects are supported by Heavy and I'm receiving no error messages in Pd. Runs perfectly fine as a standalone Pd patch. Any ideas? Here's the patch, and I'll attach the crash report below.

#N canvas 396 282 450 300 10;
#X obj 288 110 table \$0tanh 4096;
#N canvas 154 182 557 744 mktanh 0;
#X obj 80 -50 inlet;
#X obj 89 338 outlet;
#X obj 91 181 * 2;
#X obj 93 202 exp;
#X text 145 214 exp2x-1 / exp2x +1;
#X obj 93 244 - 1;
#X obj 96 224 t f f;
#X obj 122 245 + 1;
#X obj 100 274 /;
#X obj 294 180 outlet;
#X obj 94 78 t f f;
#X obj 95 109 / 2048;
#X obj 94 131 - 1;
#X obj 91 155 * 6.28319;
#X text 159 157 2pi;
#X obj 81 4 until;
#X obj 80 32 int;
#X obj 105 52 + 1;
#X obj 126 23 mod 4096;
#X msg 81 -21 4096;
#X connect 0 0 19 0;
#X connect 2 0 3 0;
#X connect 3 0 6 0;
#X connect 5 0 8 0;
#X connect 6 0 5 0;
#X connect 6 1 7 0;
#X connect 7 0 8 1;
#X connect 8 0 1 0;
#X connect 10 0 11 0;
#X connect 10 1 9 0;
#X connect 11 0 12 0;
#X connect 12 0 13 0;
#X connect 13 0 2 0;
#X connect 15 0 16 0;
#X connect 16 0 17 0;
#X connect 16 0 10 0;
#X connect 17 0 18 0;
#X connect 18 0 16 1;
#X connect 19 0 15 0;
#X restore 165 78 pd mktanh;
#X obj 163 110 tabwrite \$0tanh;
#X obj 165 55 loadbang;
#X obj 11 8 inlet~;
#X obj 11 159 outlet~;
#X obj 11 39 *~ 768;
#X obj 11 61 +~ 2048;
#X obj 11 88 clip~ -2048 2048;
#X obj 11 114 tabread4~ \$0tanh;
#X text 155 12 tanh distortion;
#X connect 1 0 2 0;
#X connect 1 1 2 1;
#X connect 3 0 1 0;
#X connect 4 0 6 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 8 0 9 0;
#X connect 9 0 5 0;

I should also note that the Heavy servers seem unable to reliably handle a download request for my patch -this started a few iterations ago, and I thought it may have just been a one time thing, but so far the webpage has consistently timed out trying to process a download request for a compiled Unity plugin of my patch (again for Mac OSX x86_64). I'm able to obtain the download by attempting to reload the page, but the page actually doesn't reload.

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x000000000000000e  rbx: 0x0000608000495540  rcx: 0x00007fff5fbfcbc8  rdx: 0x0000000000000037
  rdi: 0x0000000000035413  rsi: 0xffffffffffffffff  rbp: 0x00007fff5fbfcc00  rsp: 0x00007fff5fbfcbc8
   r8: 0x000000011344e940   r9: 0x0000000000000000  r10: 0x0000000000000037  r11: 0x0000000000000246
  r12: 0xffffffffffffffff  r13: 0x0000000113407288  r14: 0x0000608000495578  r15: 0x0000000113427d01
  rip: 0x00007fffb4880456  rfl: 0x0000000000000246  cr2: 0x00000001266476f0

Logical CPU:     0
Error Code:      0x01000024
Trap Number:     133

[mhroth]

@Bsangston I took a quick look and regarding your patch compile times, on account of the size and complexity of your patch, it can take up to 30 seconds for the patch to be processed in the first place, and an additional 90 seconds to generate the unity binary. When you say that the page is timing out, do you mean that you are getting an error? Or that the page simple seems to be loading for ever? And if it is the latter, how long are you waiting? Are are welcome to download the unity source and compile it locally using the included Xcode project, if that works better for you.

[mhroth]

Regarding why your patch is crashing, the culprit is probably the [until 4096] object. You are probably experiencing a stack overflow. Secondly, FYI you can't read below index 0 from a table, so your [clip -2048 2048] really gets turned into [clip 0 2048]. It may not be doing what you think that it's doing. Finally, if you want a tanh-like signal distortion, then I suggest that you use the hv.tanh object in heavylib. We use it all of the time, and it's been specifically optimised.

[bsangston]

Okay, thanks for the reply, I'll check out the hv.tanh object for sure. And with regard to compilation times, I fully expect the 30-90s wait you mentioned, but the webpage is timing out. Here's a screenshot:

Like I said, I'm able to download the patch by hitting reload, but the webpage actually never loads.

[mhroth]

Hmm. It may be that Chrome itself is timing out because the request is taking so long, rather than the heavy site necessarily doing anything bad. Have you tried the uploader script?