Closed LFSaw closed 7 years ago
For now, I put the complete (and compiling in faust and faustlive) dsp files here: https://gist.github.com/LFSaw/17a6125b113cd420eaed104a10653b20
We fixed some memory related issues some month ago. What Faust version are you using? I suggest using the GIT master branch.
I am on current master: ce5f468
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
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?
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).
Are you on OS X?
yes, as written in the gist
On 2. May 2017, at 11:55, Stéphane Letz notifications@github.com 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.
Can you test possible fix on master-dev branch ?
https://github.com/grame-cncm/faust/commit/c80f4427d6d47daec8f3bb4b9dd3c74aadbd1aa2
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...).
(quick fix as in "speedy", not "hacky" :) )
Will be merged in master soon.
I try to fix the JPVerb and Greyhole plugins and have the strange behaviour that the plugins compile fine but the server crashes immediately while booting. I assume this is due to an increased amount of memory allocated (?) since smaller FAUST plugins such as
compile and run just fine.
Help much appreciated.
This is related to https://github.com/supercollider/sc3-plugins/issues/133