Segfault when Mamba is started under NSM or RaySession

[Houston4444]

Hi. Sorry to re-engage the issue counter ;)

Mamba always crashes with a segfault when it is started from RaySession or New Session Manager.

if I start from external (RS or NSM open, with a session loaded) this way:

NSM_URL=osc.udp://my_machine:16187/ mamba

result is :

NSM: Successfully registered. NSM says: Well hello, stranger. Welcome to the party.Erreur de segmentation

"Erreur de segmentation" means segfault in french.

System: Librazik 3 Mamba version: 2.1

[brummer10]

Hi Thanks for reporting the issue. I've pushed a fix for it now to the github repository.

regards hermann

[Houston4444]

Thanks. Sorry that doesn't change anything here, it still crashes the same way.

Cheers Mathieu

[brummer10]

Can't reproduce it here any more.

[Houston4444]

I must believe you ;) ! Unfortunately crash still happens, even if I start mamba from source code in src/build/ with: NSM_URL=osc.udp://houston-machine:16187/ ./mamba

How can I do to get more logs and try to see what happens ?

[Houston4444]

oh wait... It can works now, I 've got it. Crash happens when "remember GUI states" RaySession option is activated.

With this option, ray-daemon sends to its client to show optional gui when this client replied successfully to the /nsm/client/open message (when the client is ready). It doesn't send this message if client had optional gui hidden at last save.

[brummer10]

I can't see any difference here regardless if I activate "remember GUI states" or not, mamba behave the same. So when I saved a session with gui hidden, it starts with gui hidden, regarless which option I set in RaySession. The same is true when I save the session with GUI visible.

How can I do to get more logs and try to see what happens ?

You could build the debug version (make clean && make debug), but that will properly spawn your terminal with a loootttt of messages.

[Houston4444]

This is something relative to execution speed. I forgot that mamba remembers itself its GUI state, so this feature is not for Mamba. I can see in your video that Mamba crashes when you add it. Look at the client status, it displays launch -> open -> ready -> stopped (the client status widget displays every status change at least 300ms to let user see it, in reality it goes faster than that).

RaySession send this show_optional_gui message to Mamba because it didn't received the optional_gui_shown message from it when it receives the /nsm/client/open reply. I will try to delay this message 50ms later and see what happens.

[Houston4444]

Humm, I have to set this timer to 200ms to get no Mamba crash risk at startup.

with printf I saw that Mamba crash trying to do widget_show_all: https://github.com/brummer10/Mamba/blob/master/src/MidiKeyBoard.cpp#L394

I think the problem is that we tell Mamba to show its GUI while its GUI creation is not finished.

I see many ways to workaround this problem (by preference order):

• makes Mamba starting NSM communication only when its GUI is totally instantiated
• prevent Mamba to try to show its GUI until it is truly ready
• makes Mamba reply to the /nsm/client/open when its GUI is totally instantiated
• send /nsm/client/gui_is_shown (or hidden) before to reply to /nsm/server/open (quite dirty)
• add a per client option to RaySession to not try to restore GUI visibility (shame, complex for user, rare usage)

[brummer10]

I think it is questionable to send show_optional_gui without user interaction. Default is to not show the GUI. The user should decide if the GUI should be shown or not. Still this is a multi threading issue in mamba, it seems, and I'll investigate. It may take me some day's to implement a solution, I'll report back here when I think it's done. Thanks for spotting the point (I think your analysis is totally correct) so the work needs to be done is on my side not on yours. regards hermann

[Houston4444]

Thanks.

I think it is questionable to send show_optional_gui without user interaction.

True. This was not a light question. Start hidden is nice for many programs, but very contre-intuitive for newbies. Also, when user adds a program to the session, we can be pretty sure (s)he wants to see the GUI.

But, here, we can't exclude that a very fast user on a very old machine could make it crash ;)

[brummer10]

But, here, we can't exclude that a very fast user on a very old machine could make it crash ;)

I think we could. Usual double click timeout is far above 200ms ( 500ms). I'm pretty sure that no user is able to click faster then 200ms after a message, it's more by >1sec. However, this is a issue needs to be solved far beyond this question, and as I said, I'm glad you spotted it and give me a reason searching for a solution.

[brummer10]

btw. the issue will be simply solved by show the GUI on default in mamba.

[brummer10]

Okay, I think I've solved it now with the last commit.

[brummer10]

@Houston4444 If you could confirm the Fix, we could close this issue.

[Houston4444]

Really perfect ! Everything works fine ! Good job ! It's a pleasure to work with people working so neat and so reactive. Thanks a lot.