search

muse-sequencer / muse

MusE is a digital audio workstation with support for both Audio and MIDI
https://muse-sequencer.github.io/
Other
662 stars 71 forks source link

"Select Directory" dialogs freezes MusE #646

Closed drautzburg closed 3 years ago

drautzburg commented 5 years ago

Muse 3.0.2 compiled from source

It appears, I can use the file save dialogs "Projects folder:" and "Project Path to song file" only once.

When I use them a second time, muse freezes. This can be provoked as easily as

The console output during this is

(muse3:25578): GLib-GObject-WARNING **: cannot register existing type 'GdkWindow'
(muse3:25578): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed
(muse3:25578): GLib-GObject-CRITICAL **: g_type_register_static: assertion 'parent_type > 0' failed
(muse3:25578): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

I already tried renaming my .config/MusE directory and the problem remains, so there is probably nothing wrong with my settings. I also tried a different window manager to no avail. I do however, use compiz.

drautzburg commented 5 years ago

I just noticed that I cannot create wave files (ENOSYS), i.e. I cannon record. I believe I messed up the versions of libc and libc-dev. Unless you can easily reproduce the "Select Directory" issue, I suggest, you don't bother as it may be caused by the way I compiled MusE.

I will report once I fixed the issue.

drautzburg commented 5 years ago

So, while I did have a libc that was "installed locally", this did not really cause any trouble (and why should it). The ENOSYS problem was caused by a track called "Lead/Guitar". It seems, that slashes in track names are a really bad idea. You may want to safeguard against this.

The file-chooser errors seem to be a genuine MusE problem. I moved all my local gtk config files out of the way and even started MusE as a different user (no compiz) and the problem did not go away.

terminator356 commented 5 years ago

Hello again Martin. I could not reproduce the naming slash problem. It should not cause any trouble because slashes are not reserved xml characters and therefore are treated like any other character by our code. I tried in German (de) locale, on this English PC, but no trouble found.

[Edit:] All of this on 3.0.2 release that I have.

If you wish, post or send me a *.med file with these track names and I'll take a look.

I am aware of a long-time slight bug in the file dialogs where, something like, if you click Cancel from the newer fancier dialog then try to click 'Save As' later it takes you to the much older dialog we had from MusE-2 which looks like an old Qt file dialog. Can't remember exactly how to reproduce but it was minor, not show-stopping.

But I am not aware of anything like this. Why are you getting glib errors? MusE does not use G (Except for some LV2 UIs when opened. Are such UIs open at this time?) Does this mean you are running say Fedora or other G distro?

On a lighter 'note', perhaps the "Lead Slash Guitar" track is waiting for... ... Slash himself to show up ;-)

drautzburg commented 5 years ago

I forgot to mention that the slash problem concerns an audio track. MueE tried to create a file named "TRACK_Lead/Guitar_TAKE_1.wav". You may want to prohibit slashes in the names of wave tracks, or better: "escape" them when construcing the filename.

I don't know why i am getting glib errors. I believe the glib errors appear with the first dialog and the second dialog (which freezes Muse) does not produce messages.

I am using Debian with compiz. I had to compile mesa myself to get this to work, which required a newer libc. That's why I initially suspected some libc vs libc-dev incompatibility, but at a closer all look, everything looks consistent.

No LV2 UIs where open at the time.

I just noticed that in Global Settings, I had "Use project save dialog" checked. When I uncheck this, the problem goes away.

terminator356 commented 5 years ago

Ah I see. The wave track naming thing was added a long time ago for the purpose of the multiple 'takes' feature, I think (I forget how to activate it, you just push a key and MusE automatically sets up for a quick 'retake'.) I'll take another look. The glib thing, hm, not sure. Looks like it's your system's window manager, not MusE's fault. One thing to try: Go to Settings > Appearance settings and choose a different theme in the 'Themes' section. Be sure to try different ones like Fusion, Plastique, or Windows. The various themes on the system have certainly caused us headaches in the past, with freezing and so on. Breeze and Oxygen had a bug upstream which I help fix. And... 3.0.2 is kind of getting old now. We've got a new 3.1-pre release available. And even better, get the git master. This step alone might just solve all the trouble.

drautzburg commented 5 years ago

I compiled 3.1-pre and set the theme to Fusion, but MusE still freezes. I tried the same thing as a different user with a standard gnome setup and it also froze.

drautzburg commented 5 years ago

I noticed, that similar things happen when I edit the list of soundfonts. I can use "Load" only once.

drautzburg commented 5 years ago

I played around with the soundfont dialog some more. Here are the steps:

It appears, you can do other things between the first and the second Load i.e the two loads don't need to be consecutive. The second Load will still freeze MusE.

To rule out that some of my settings or my compiz/emerald setup messed up things, all of this was done as a guest user under XFCE. The .config/MusE directory of that user was cleared. MusE itself was compiled from git Master without changing anything except the PREFIX.

Other things I tried:

I should mention that I have a new machine which is way faster than my old machine, where I didn't see this problem. I now have a 6/12 core i7 machine.

I attach the environment variables and the tail of an strace writeout. Strace usually produces a lot of output (quite a bit of polling seems to happen). But after the freeze it comes to a complete halt.

xxxenv.txt xxxstrace.txt

Some other minor things I noticed:

drautzburg commented 5 years ago

I tried to obtain a gdb backtrace from MusE in the frozen state. I am no expert in doing such things, but here is what I did

I attach the result xxxbt.txt

This was done as user martin, i.e. with compiz/emerald

drautzburg commented 5 years ago

Here is what I get from/proc/<pid>/stack before and after the freeze:

before:

/proc/25674 >cat stack
[<ffffffff8604ed45>] poll_schedule_timeout+0x45/0x70
[<ffffffff8604ffb5>] do_sys_poll+0x395/0x510
[<ffffffff86050901>] SyS_poll+0x71/0x130
[<ffffffff864c267b>] entry_SYSCALL_64_fastpath+0x1e/0xa9
[<ffffffffffffffff>] 0xffffffffffffffff

After (frozen)

/proc/25674 >cat stack
[<ffffffff85f128aa>] futex_wait_queue_me+0xca/0x120
[<ffffffff85f135ed>] futex_wait+0x10d/0x250
[<ffffffff85f158a5>] do_futex+0x2f5/0xd20
[<ffffffff85f16353>] SyS_futex+0x83/0x180
[<ffffffff864c267b>] entry_SYSCALL_64_fastpath+0x1e/0xa9
[<ffffffffffffffff>] 0xffffffffffffffff
drautzburg commented 5 years ago

Sorry for being so noisy, but the file dialog problem gets under my skin, even though it doesn't impede working with MusE that much. The thing is, on my new machine MusE is less stable than on my old machne and I don't know why. The file dialog problem is at least something I can put my finger on and after all, it may point to something fundamental.

I looked up the glib messages and I don't think they are related to a race condition, but are caused by wrong initialization code. So, my hint that I have a faster machine is probably irrelevant. The fact that I have a new Debian installation might be way more relevant.

As for why on earth MusE, a qt app, uses GdkWindow , I noticed this line in the gdb backtrace:

qt5/plugins/platformthemes/libqgtk3.so

This is like 6 stackframes down from any MusE code and deep in Qt land. When I get back home from my Easter trip, l will investigate where this came from.

Still curious to hear whether you can reproduce the problem (try the sounfont problem because unlike "Project save" it is not affected by a setting AFAIK)

drautzburg commented 5 years ago

After running apt-get purge qt5-gtk-platformtheme the problem is gone.

I believe this is a known QT problem, for which there is a workaround (other than removing qt5-gtk-platformtheme). See here.

terminator356 commented 5 years ago

Hi Martin, sorry for the very late reply, been very busy. Thanks for the investigations. Given the instructions above I could still not reproduce the problem. This appears to be not related to MusE at all, rather the Gnome system.

According to the bug report mentioned, one user tried a workaround by not passing a parent to the file dialog, and he said it worked. We do pass a parent to the dialog. If I make a change to our code so that no parent is passed, would you still be in a position to test it? ie. can you revert your system to make the problem occur and then test my proposed fix, if I commit it, to see if it works?

drautzburg commented 5 years ago

I could reinstall qt5-gtk-platformtheme, check if I still see the freeze, then recompile MusE with your change and see if it's gone.

BTW: how would I recompile MusE? Just git pull and then make?

terminator356 commented 5 years ago

Hi, sorry for the delay. I have attempted to fix this by NOT supplying a parent to the QFileDialog, as suggested by a user in the Qt bug report. The fix is in git master now.

Git pull and make should do it, I'd say.

If you could still test whether it freezes with the qt5-gtk-platformtheme, that would be great. Note: I suspect that you'll want to go to Settings > Appearance Settings and change the 'Theme', as I mentioned before try various themes such as Fusion, Windows, Gtk etc. to be sure that this does solve the problem. Various specific themes have caused freezing for us before (ex. Breeze and Oxygen, fixed upstream at KDE about two years ago).

Thanks.

drautzburg commented 5 years ago

Tim,

I'm afraid neither your changes nor changing the theme solve the problem. Here is what I did:

terminator356 commented 5 years ago

OK Thanks for tests. I have these packages installed: libqt5-qtbase-platformtheme-gtk3 and libqt5-qtstyleplugins-platformtheme-gtk2 but I have no trouble with any of the themes.

So it must be a system thing. I think you said it's XFCE? It's not a KDE-based distro, correct?

drautzburg commented 5 years ago

Tim,

my distro is just a regular debian 9.4 ("Stretch"). It includes KDE, Gnome and XFCE and some more. The Xsession I start however, is indeed a XFCE session, though could reproduce the problem when logged in as a different user, using a stock gnome session (not sure whether I tried a stock KDE session, but I believe I did).

The packages you mention are not available in the debian repository, at least not under these names. I am offered these packages with "platformtheme" in their names:

/home/martin >apt-cache search platformtheme
qt5-gtk-platformtheme - Qt 5 GTK+ 3 platform theme
qt5-style-plugins - Qt 5 extra widget styles
qt5-flatpak-platformtheme - Qt 5 Flatpak platform theme

I checked the google matches for these "platformthemes" and qt5-gtk-platformtheme indeed seems to be somewhat exotic. Also it is not required by any other package but only recommended by libqt5gui5. Still your platformthemes appear even more exotic than mine.

Yours (Opensuse?):
  libqt5-qtbase-platformtheme-gtk3           521 matches
  libqt5-qtstyleplugins-platformtheme-gtk2   257 matches

Mine (Debian)
  qt5-gtk-platformtheme                    20200 matches <--
  qt5-style-plugins                         3400 matches
  qt5-flatpak-platformtheme                  422 matches

From these, I only had the first one installed when the freeze occurred. Is there any chance you can test this on a Debian based distro like Ubuntu or plain Debian? I have a feeling that MusE and qt5-gtk-platformtheme just don't play together well.

In case it matters, these are my glib and gtk packages:

ii  libgtk-3-0:amd64         3.22.11-1         amd64  
ii  libgtk2.0-0:amd64        2.24.31-2         amd64  
ii  libglib2.0-0:amd64       2.50.3-2          amd64
kybos commented 3 years ago

I tried to make MusE 4 as independent of all those buggy styles and themes as possible.

If this special problem still persists in the current version, try to uncheck the following option:

Settings->Appearance->Themes->Use native standard dialogs

That at least solved similar problems for me (and was the reason why I added this option...).