Freeze when opening FileChooser

… to be precise about fallbacks, it looks like there are already fallbacks implemented (juce_linux_FileChooser.cpp):

Szenario 1)

  • There is no zenity (e.g. it’s removed by ‘sudo apt-get remove zenity’)
  • kdialog has been installed (e.g. using ‘sudo apt-get install kdebase-bin’)

In this case Projucer falls back automatically to kdialog.

Note for this szenario: In case you have to install kdialg (sudo apt-get install kdebase-bin), then start first once kdialog in a shell (e.g. 'kdialog --yesno “yes/no”). kdialog seems to do some user configs on first startup which causes kdialg to crash when started first time directly through Projucer.

Szenario 2)

  • zenity is installed
  • kdialog is installed as well
  • variable KDE_FULL_SESSION is set to true (for test e.g. you execute in the shell from which you start Projucer
    export KDE_FULL_SESSION=true

In this case Projucer doesn’t check first the existence of zenity but invokes directly kdialog instead

… to finalize my filechooser-weekend, the driver for the freeze must be a change introduced in gtk±3.17.8 in gtkfilechooserwidget.c (access check for parent folder, see diff first image below.) Somehow zenity gets frozen at munmap() on Linux’ on pyhsical systems, VMWare and Virtualbox but not on Parallels Desktop guests (see second image with comparison of strace -ff attached to zenity left side on parallels desktop, right side on Vbox guest).
Might be the new parent folder access check in gtkfilechooserwidget.c conflicts with an access to the same parent folder from within juce_linux_FileChooser.cpp ?


Thanks for looking into this. It’s strange obviously as zenity runs in a completely different processes. I think the quick fix is to not use native file chooser on Linux for now. I’ll make the necessary changes.

We have had the same experience, on some Linux boxes those native file choosers just lock up or don’t work for no discernible reason. And frankly I don’t think that can be fixed in any way. This is the kind of stuff you agree to put up with if you install Linux on your computer.

So by default our app uses the JUCE file chooser (on Linux), and if an user really wants native choosers, he can enable an option and cross his fingers.


Roeland

PS. I’m also quite surprised that by default the ChildProcess mixes the output on stdout and stderr together. It’s almost never possible to do anything reliable with this mix. A lot of programs will not flush stdout or stderr when emitting a newline if not writing to a terminal, so it is quite likely that even some individual lines will contain a mix of data from stdout and stderr.

@Roeland, complitely agree.
My assumptions are going into the same direction, there must be a combination of

a) the code change for gtkfilechooserwidget.c from gtklib version 3.17.7 to 3.17.8 which I interpret as a security improvement (mitigation of escaping to shell when using kdialog etc.)

and

b) the way juce filechooser linux is forking and calling kdialog, where also timing issues could explain different behaviours on different installations, e.g. access issue from the child process to folder/file which is now locked with the gtklib change from the parent process.

… what makes the behaviour unique to JUCE/Linux and is not observed by other kdialog callers using gtk library after 3.17.7.
If I would have more time actually I would now isolate the calling function into a small test program and then sort out how to modify the calling function.
However, as mentioned for my need I’m using Juce more for musical programming and not as a File Explorer,. Therefore the embedded file chooser is good enough for me as well.

OK, before I turn off native file choosers on Linux can someone test my quick fix on my private branch:

This closes all other file and directory descriptors before calling the child process. Note that this hasn’t been tidied up yet. For example, it will only work if zenity is located at /usr/bin/zenity.

If this works, then I’ll add a flag to ChildProcess to close all file descriptors after forking.

Thanks a lot, I made two fresh Linux installations one for the Debian family - Ubuntu 16.04 LTS and one for the RPM familiy - Fedora 23_10, followed the steps in my own description in this thread, compiled the Projucer and … it works perfectly now!

:relaxed::+1:
-Tom

i also have had this problem recently but because im usually using debian testing i have been ignoring it - but i noticed this thread today so now i peeps on stable distros are seeing this too

@fabian - i tried your patch above and it allowed the native dialogs to open properly on debian with LXDE and also arch with deepin desktop

1 Like

Hi Fabian,

I have recently started trying out JUCE on Linux too (after a couple years with OSX).

Everything worked flawlessly bar this file chooser issue but the hack on your private branch solved it with no issues on ubuntu 16.04

Will this be added to the main repo any time soon ? Would be handy to be using the main repo in future.

Regards

OK. I’ve cleaned up the code and added an option to close all file descriptors of a ChildProcess on Linux. Can people who had issues with this retest my patch on my private repo? Note, you’ll probably need to re-clone the repo as I did a force push.

Fabian, the latest patch does not work for me - the app freezes just as before - there must be something significantly different from last week’s patch

Ahh this is super annoying. Can you please test the latest master on my private repo? Thank you for your help.

Hi Fabian, I just took a fresh clone and it’s still the same as bill-auger reported. Freezing as before.

If you need the last working clone from May 5 for easier comparison, I’ve uploaded it here.

I just can’t find a VM to re-produce this problem. I’ve just installed Fedora 23 on a parallels VM with the latest JUCE tip and the filechooser works fine. Can anybody suggest a linux distro/version that will re-produce this bug in a parallels VM?

yes, that’s the curiosity on Parallels Desktop VM’s there is no issue see my post earlier in the thread above. It happens on physical Linux, on VMware and Vbox guest, only not on Parallels Desktop.
And it happens when gtklib 3.17.8+ is in place, not gtklib 3.17.7 and below. As I interpret the change in the gtkfilechooserwidget introduced with gtklib 3.17.8 as security improvement. My further hypothesis regarding the fact that this security fix doesn’t have an impact on Parallels Desktop VM hosted Linux only is that Parallels Desktop interacts in a way between OSX filesystem and guest filesystem which make this change ineffective - by chance with a “positive” side effect on our case here.
Therefore to reproduce it you have to download Virtualbox (free) or VMware it doesn’t matter if hosted on Windows or OSX - I tried it on both with same result, it freezes.

1 Like

OK. This is finally fixed on the latest tip of the develop branch. Thank you for all your debugging and help!

1 Like

Can reproduce this on Manjaro 3.16 (Arch fork) with Openbox Window Manager and GTK 2.24.28.

But it works fine after disabling the native filechooser (thanks tomotello) , so perhaps it is not the most urgent issue, as it isn’t a blocker per se.

@Fabian, thanks a lot, I just took the latest develop branch, works perfect now.

@Loudatio, I assume you didn’t take the latest develop branch as Fabian noted in his post before, e.g. by taking a new clone with the branch option set to develop ( git clone -b develop https://github.com/julianstorer/JUCE ).

1 Like

confirmed on debian/testing LXDE develop branch is fixed - ty @fabian

Regular download (from the site) didn’t work on Ubuntu 16.04. Tried the developer branch, and I can confirm that it no longer freezes. Thanks!

1 Like