interpreter crashes after server boot when very large scd file is currently open

[telephon]

I am not sure what is wrong with my system, but all builds, including the downloaded 3.7 binary crash the interpreter on server start. I've cleaned/rebuilt sc serveral times, and rebooted the system.

Time Awake Since Boot: 2600 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

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

VM Regions Near 0x7fff58ff5a98:
    MALLOC_TINY            00007f8744800000-00007f8744900000 [ 1024K] rw-/rwx SM=PRV  
--> STACK GUARD            00007fff558d5000-00007fff590d5000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
    Stack                  00007fff590d5000-00007fff598d5000 [ 8192K] rw-/rwx SM=PRV  thread 0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   sclang                          0x0000000106469f46 ScIDE_SetDocTextMirror(VMGlobals*, int) + 150
1   sclang                          0x0000000106344d41 doPrimitive(VMGlobals*, PyrMethod*, int) + 209
2   sclang                          0x0000000106386b0d Interpret(VMGlobals*) + 24525
3   sclang                          0x0000000106380964 runInterpreter + 36
4   sclang                          0x000000010638db40 runLibrary + 80
5   sclang                          0x00000001063be1f1 SC_LanguageClient::runLibrary(PyrSymbol*) + 33
6   sclang                          0x00000001063c396a SC_TerminalClient::interpretInput() + 154
7   sclang                          0x00000001063c7d9e void boost::asio::asio_handler_invoke<boost::_bi::bind_t<void, boost::_mfi::mf0<void, SC_TerminalClient>, boost::_bi::list1<boost::_bi::value<SC_TerminalClient*> > > >(boost::_bi::bind_t<void, boost::_mfi::mf0<void, SC_TerminalClient>, boost::_bi::list1<boost::_bi::value<SC_TerminalClient*> > >&, ...) + 110
8   sclang                          0x00000001063c7cd4 boost::asio::detail::completion_handler<boost::_bi::bind_t<void, boost::_mfi::mf0<void, SC_TerminalClient>, boost::_bi::list1<boost::_bi::value<SC_TerminalClient*> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) + 84

[timblechmann]

a backtrace with debugging symbols might help. maybe pink @muellmusik, as afaict he implemented most of the document stuff for the ide

[miczac]

@telephon , oh, I see now. would be interesting if the backtrace of your sclang crash looks similar to mine in #1824.

[telephon]

It concerns all sc3.7 versions, both self-built and downloaded binary. I'm trying to find a reason in the system. a reinstall of qt5 didn't make a difference.

[telephon]

ok, seems to be some file in the config data.

[telephon]

OK, solved. It was a very large scd file (9.3 MB) that was automatically reopened by ways of the current session. When starting scserver, as it seems, this just tipped it over (would be interesting to know what it was.)

[miczac]

I was just about to ask "Time-Wave Synthesizer?" - then read your posting on sc-users. ;)
However, again, sclang may refuse to work, throw errors etc, but shouldn't crash.
So, IMHO this issue is still valid.
This code-sermon is a good benchmark. ;)

[telephon]

Definitely caused a few grey hairs ;)

[timblechmann]

btw, a backtrace with debugging symbols (read: line numbers) might help

[timblechmann]

... or reading the code: ScIDE_SetDocTextMirror

#ifndef _WIN32
    char text[length + 1];
#else
    char * text = (char*)_alloca(length + 1);
#endif

putting several mb on the stack will cause a stack overflow. someone might want to change the code to use malloc/free instead.

[telephon]

btw, a backtrace with debugging symbols (read: line numbers) might help

like this?

 #include <execinfo.h>
         #include <stdio.h>
         ...
         void* callstack[128];
         int i, frames = backtrace(callstack, 128);
         char** strs = backtrace_symbols(callstack, frames);
         for (i = 0; i < frames; ++i) {
             printf("%s\n", strs[i]);
         }
         free(strs);

[timblechmann]

for make/ninja builds: -DCMAKE_BUILD_TYPE=Debug. xcode has multiple configurations in the same project, but it is hidden somewhere in the user interface ...

[telephon]

Ah yes, thank you - actually I had configured it with these arguments. But maybe the crash report doesn't show the line numbers nevertheless. Hm, "user friendliness" ...

[timblechmann]

well, unless you manually remove the -g from the compiler flags, it will show the line numbers ...

[telephon]

ah, is it so - ok, I'll check again when I can

[miguel-negrao]

... or reading the code: ScIDE_SetDocTextMirror

#ifndef _WIN32
char text[length + 1];
#else
char * text = (char*)_alloca(length + 1);
#endif

putting several mb on the stack will cause a stack overflow. someone might want to change the code to use malloc/free instead.

@timblechmann is #1849 the right way to do it ? I tested opening a 14MB file, and although it took a long time, no crash occurred.

[timblechmann]

@miguel-negrao yes, though the same code should also be used in the windows codepath.

[miguel-negrao]

fixed in 044095a.