[ Fixed ] Ancient crashes when loading another song or file > 'new' or 'close'

[tramp]

Yes, I've seen. Hence my comment. When you run ipatch_init() in your host constructor, the issue with Fluida, or any other plug using fluidsynth, will be solved. As then, your host will be the owner of the instance counter of libinstpatch and it wouldn't unload when close a plug using it.

[Tim E. Real]

I am attempting to add the fix now.
But I am hitting a familiar brick wall:

In our main.cpp when I include

Code: Select all

#include <libinstpatch/libinstpatch.h>

I get several warnings like this that have been turned into errors:

Code: Select all

/usr/include/libinstpatch-2/libinstpatch/IpatchSF2Gen.h:239:13: error: Deprecated pre-processor symbol, replace with  [-Werror]
/usr/include/libinstpatch-2/libinstpatch/IpatchItem.h:74:22: error: ‘GStaticRecMutex’ is deprecated: Use 'GRecMutex' instead [-Werror=deprecated-declarations]

Note the useless partial error info there.
Although whatever it is trying to tell me really needs to be fixed in libinstpatch !

So I am trying to suppress these errors but I cannot seem to find the right #pragma
I tried

Code: Select all

#pragma GCC diagnostic ignored "-Wdeprecated-declarations"

which got rid of one of the warnings but not all the rest.

I've been through this before and it's frustrating.
Previously I had to put a couple of our code files into separate compile modules - just so I could specify -Wno-error !
Nothing else worked.
It always seems to be the glib stuff that does this.

Any suggestions anyone, while I continue to bang my head against this brick wall?

[Tim E. Real]

After some googling, this seems to get rid of all the deprecation warnings:

Code: Select all

#ifndef GLIB_DISABLE_DEPRECATION_WARNINGS
#define GLIB_DISABLE_DEPRECATION_WARNINGS
#endif

[Tim E. Real]

OK @Impostor
A fix was pushed in github master.
No more crashes here.
Please test and lemmy know if any trouble.

[Impostor]

OK @Impostor
A fix was pushed in github master.
No more crashes here.
Please test and lemmy know if any trouble.

Right on!

[Impostor]

OK @Impostor
A fix was pushed in github master.
No more crashes here.
Please test and lemmy know if any trouble.

I get loads of warnings during compiling; a lot was already present in previous versions, but also a lot of new ones (mostly glib and libinstpatch related it seems). Compiling proceeds to 100% though.

Opened new project and added fluida repeatedly. First I got a crash to desktop at the third or so instance (probably just a chance occurrence). But the second sequence went well over 10 repeats before I got bored and gave up trying to provoke a crash. So it seems fixed indeed!

Hope you didn't bang your head against the wall too often.

[Tim E. Real]

Yes I know we get a lot of glib warnings with our LV2 gtk UI code, fluidsynth (deprecated stuff), and instpatch.
They are warnings from deep inside glib gtk and so on.
That's why I had to put some of that stuff into separate modules so I could use -Wno-error.
But, I wish I had known about GLIB_DISABLE_DEPRECATION_WARNINGS
Had I known that, those changes might not have been necessary

Hm, it crashed once? Unacceptable in production usage, eh!
I'll keep my eye on that. It could have been something completely unrelated.
Let me know if you can capture console output if it happens again.

[Tim E. Real]

On advice of brummer (at fluida), I have added ipatch_close() and re-arranged the calls to ipatch_init().

Hopefully the reference counting will then unload the library when appropriate.

Again, rattle the chains if any trouble.

[Tim E. Real]

Hey all, hey@Impostor and @onefang

A typo crept into the fix at 13.05.2023 where I wrote:

Rewrite of 08.05.2023: Use alternate method for top level closing (wait for destroyed signals).

The typo caused crashes when loading or reloading and unusual errors about "route already exists".
It's because the midi configuration (devices, ports, connections) were not being cleared to make way
for what was about to be loaded from the song file.

If anyone was thinking "Stable on reload? What is he talking about? It's worse!", sorry about that.
Hope the irony didn't drive you nuts too much.

It should be fixed now.

I see also there is a remaining relatively benign error when reloading a song which has the Master Track Graphic tab open.
You may see an error and the master editor tab does not re-open, and you may have to manually re-open it:

Code: Select all

QMdiArea::setActiveSubWindow: window is not inside workspace

Also I get odd xml tag warnings like this:

Code: Select all

WaveEdit: unknown tag <ypos> at line 3732

I am not sure yet if they are related to any of this. They sorta, kinda seem to be...

All for now.

[onefang]

I just now updated my source and rebuilt it. Deleted the installed directory and installed it. Deleted my config directory. And I can still get it to crash by just loading this untitled.med then loading CrashTestDummy.med.

Hmmm, no more file uploads? Oh well, that's what my new web site is for.

https://untalenz.rocks/untitled.med.gz
https://untalenz.rocks/CrashTestDummy.med.gz

[Impostor]

Yep, output of muse4 -D:

Code: Select all

MidiJackDevice::queueEvent() evTime:13079603 < syncFrame:13079808!!
ACTIVE TOPWIN CHANGED to '<None>' ((nil))
Segmentation fault (core dumped)

Maybe related:
viewtopic.php?t=23419

[Impostor]

I just now updated my source and rebuilt it. Deleted the installed directory and installed it. Deleted my config directory. And I can still get it to crash by just loading this untitled.med then loading CrashTestDummy.med.

Hmmm, no more file uploads? Oh well, that's what my new web site is for.

https://untalenz.rocks/untitled.med.gz
https://untalenz.rocks/CrashTestDummy.med.gz

The problem may exist in your untitled.med. Loading that one opens 6 jack midi in- and output ports.
Then MusE autoconnects port 6 (in and out) of this to my system's jack ports (which are apparently actually my alsa midi through port 0 in and out)*.

Opening another project doesn't remove the 6 MusE jack ports opened by untitled.med. Unless that new project repopulates those ports with its own.

*probably not the problem. If I block my system's jack midi ports from MusE (connecting them to something else exclusively in qjackctl) then the crash still happens.

[onefang]

I just now updated my source and rebuilt it. Deleted the installed directory and installed it. Deleted my config directory. And I can still get it to crash by just loading this untitled.med then loading CrashTestDummy.med.

Hmmm, no more file uploads? Oh well, that's what my new web site is for.

https://untalenz.rocks/untitled.med.gz
https://untalenz.rocks/CrashTestDummy.med.gz

The problem may exist in your untitled.med. Loading that one opens 6 jack midi in- and output ports.
Then MusE autoconnects port 6 (in and out) of this to my system's jack ports (which are apparently actually my alsa midi through port 0 in and out)*.

Opening another project doesn't remove the 6 MusE jack ports opened by untitled.med. Unless that new project repopulates those ports with its own.

*probably not the problem. If I block my system's jack midi ports from MusE (connecting them to something else exclusively in qjackctl) then the crash still happens.

Opening 6 JACK MIDI in and out ports is the default, at least on my system with the MusE config removed. My JACK has system -> midi_capture_1 2 and 3 / midi_playback_1 2 and 3, as well as a2j's Midi through and the two actual MIDI devices (in and out each). So the default for MusE is to open ports for each of those.

Well technically it's only one MIDI device, but it has an Editor in/out as well as the actual in/out.

Those two files are just my "smallest files that show the problem", and untitled.med is just "open up MusE, add a synth and a MIDI track, save it".

[Impostor]

The problem may exist in your untitled.med. Loading that one opens 6 jack midi in- and output ports.

If I remove all except the first two jack midi ports from the untitled project, and save, then crashtestdummy won't crash anymore when loaded after untitled, so that's a clue...

Edit: eh, once it didn't. Now it crashes again...

[Impostor]

Opening 6 JACK MIDI in and out ports is the default, at least on my system with the MusE config removed. My JACK has system -> midi_capture_1 2 and 3 / midi_playback_1 2 and 3, as well as a2j's Midi through and the two actual MIDI devices (in and out each). So the default for MusE is to open ports for each of those.

I have this line in my config file:
<configure_midi_ports>0</configure_midi_ports>

I only get Alsa ports by default (though not auto-enabled).