s.queryAllNodes from remote crashes scsynth

[sensestage]

At least calling this from a remote laptop.

[sensestage]

works fine when calling it from a local sclang.

[giuliomoro]

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

[sensestage]

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.

[giuliomoro]

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"

[sensestage]

Other messages that crash scsynth:

"/s_get" "/s_getn" "/c_get" "/c_getn"

[sensestage]

But when sclang is run from the Bela IDE it does not crash scsynth.

But just signals a mode switch.

[sensestage]

Reproduce with:

• start scsynth on the bela
• make a remote connection from your laptop's SCIDE

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 )

[giuliomoro]

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.

[sensestage]

oh, that is good news!

It does explain why I got it with all the messages that create a big_scpacket.

[giuliomoro]

So this can be closed.