Closed sensestage closed 5 years ago
works fine when calling it from a local sclang.
when called from a local sclang it is
[ "/g_dumpTree", 0, 0 ]
when called from a remote IDE it is
[ "/g_queryTree", 0, 0 ] Segmentation fault
Ok, might be good to test also sending dumpTree from remote sclang:
s.sendMsg( "/g_dumpTree", 0, 0 );
The post should then happen in the terminal on the bela.
From remote
s.sendMsg( "/g_dumpTree", 0, 0 );
dumps on the terminal
NODE TREE Group 0
1 group
From local sclang:
s.sendMsg( "/g_queryTree", 0, 0 );
causes segfault.
So the issue is "/g_queryTree causes segfault"
Other messages that crash scsynth:
"/s_get" "/s_getn" "/c_get" "/c_getn"
But when sclang is run from the Bela IDE it does not crash scsynth.
But just signals a mode switch.
Reproduce with:
Server.default = s = Server("belaServer", NetAddr("192.168.7.2", 57110));
OSCFunc.trace(true,true);
s.options.maxLogins_( 4 );
s.dumpOSC(1);
s.initTree;
s.startAliveThread;
Then send the message:
s.queryAllNodes( true )
Right, I am 99% sure this was due to stack overflow due to the small-ish size of the default stack of the Xenomai thread. The big_scpacket
allocated in meth_g_query_tree()
is - after all - 64k ... I now increased the size of the stack on Bela to 128KiB by default.
This should be fixed by using Bela code https://github.com/BelaPlatform/Bela/commit/a707c9d7fa95b890aafd3db95193e16279a534cf or later.
oh, that is good news!
It does explain why I got it with all the messages that create a big_scpacket.
So this can be closed.
At least calling this from a remote laptop.