faust2supercollider: complex plugins crash scsynth while booting about faust

[LFSaw]

For now, I put the complete (and compiling in faust and faustlive) dsp files here: https://gist.github.com/LFSaw/17a6125b113cd420eaed104a10653b20

[sletz]

We fixed some memory related issues some month ago. What Faust version are you using? I suggest using the GIT master branch.

[LFSaw]

I am on current master: ce5f468

[LFSaw]

I added the crash report and build/reproduce instructions to the gist (see above).
Apparently, it is a seg-fault, I copied important bits of the trace below:

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x00007fff5e06b9f8
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x7fff5e06b9f8:
    MALLOC_SMALL           00007f8063800000-00007f8065800000 [ 32.0M] rw-/rwx SM=PRV  
--> STACK GUARD            00007fff5a8f0000-00007fff5e0f0000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
    Stack                  00007fff5e0f0000-00007fff5e8f0000 [ 8192K] rw-/rwx SM=COW  thread 0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   GreyholeRaw.scx               	0x0000000103d8f8ad load + 77
1   scsynth                       	0x0000000101335109 PlugIn_LoadDir(char const*, bool) + 249 (vector:1587)
2   scsynth                       	0x00000001013351ac PlugIn_LoadDir(char const*, bool) + 412 (SC_Lib_Cintf.cpp:395)
3   scsynth                       	0x00000001013351ac PlugIn_LoadDir(char const*, bool) + 412 (SC_Lib_Cintf.cpp:395)
4   scsynth                       	0x0000000101334f7f initialize_library(char const*) + 607 (SC_Lib_Cintf.cpp:217)
5   scsynth                       	0x000000010134d1a6 World_New + 614 (SC_World.cpp:338)
6   scsynth                       	0x000000010131453a main + 1770 (scsynth_main.cpp:331)
7   libdyld.dylib                 	0x00007fff8f50e235 start + 1

[sletz]

This object takes a lot of heap memory (something like 8923344 bytes) as well as static global memory taken by the prime_delays table (which take 1302 integer). Could the static global memory size be the issue?

[LFSaw]

good point but the previous version (from some 4 years ago) used to work... and I did not change anything in the dsp file despite integrating the primes into the dsp file rather than having them as an external c-header function.

also, increasing memory to the server by

s.options.memSize_(65536 * 4); // in kilobyte

did not do the trick... Is the memory allocated at scsynth startup? AFAIK not, that is only where the interface table (holding pointers to the UGen plugins) is loaded... (that is my simple understanding, I might be wring here).

[sletz]

Are you on OS X?

[LFSaw]

yes, as written in the gist

…

On 2. May 2017, at 11:55, Stéphane Letz ***@***.***> wrote: Are you on OS X? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[sletz]

Can you test possible fix on master-dev branch ?

c80f442

[LFSaw]

I checked it out, run the appropriate commands and managed to make it work with the 2 dsp files.
Thanks for the quick fix!

Will this go into the master branch?

Btw., it seems that the mem-check in line 418 of supercollider.cpp is never reached by scsynth (not necessarily hazardous since the MAlloc fail is catched otherwise...).

c80f442#diff-2e586352d40979469e42302965f6d390R418

[LFSaw]

(quick fix as in "speedy", not "hacky" :) )

[sletz]

Will be merged in master soon.