Steps to recreate problem: 1. Choose commandline app (e.g. 'cplay') 2. Add launcher for chosen app, without selecting "run in terminal" Result: xfce freezes. Mouse can move, but cannot select anything (other windows, etc.). When switching to a virtual terminal then back to X, panel graphic is not refreshed and instead is just a gray box. Expected Behavior: program should just not run, or the command should not be run. All of xfce should not freeze. Reproducible: Always Steps to Reproduce: 1. Choose commandline app (e.g. 'cplay') 2. Add launcher for chosen app, without selecting "run in terminal" Actual Results: Result: xfce freezes. Mouse can move, but cannot select anything (other windows, etc.). When switching to a virtual terminal then back to X, panel graphic is not refreshed and instead is just a gray box. Expected Results: Expected Behavior: program should just not run, or the command should not be run. All of xfce should not freeze.
Yeah, this is a known issue with X. I tried to solve it once, but it failed. Anyone who is willing to work on this is most welcome to try.
Created attachment 298 Prevents X from freezing when launching console app (Fingers crossed) I played around with this bug, and I still don't understand it, but the attached seems to fix the problem. At the very least, it neatens the indents =) All I've done is add flags to g_spawn_async_with_pipes() to close of stderr and stdout. If people could test this to make sure it actually makes a difference, it would be good. Also, if anyone could shed some light on *why* it works (at least for me), that would also be great.
an additional note to my previous patch: it seems like all output streams must be directed to /dev/null for it to work, so leaving stderr open isn't any good. I haven't tried yet, but possibly directing stderr to an error log of some sort would work, and keep error logs around. Also, I still haven't figured out why this patch works, and I'm not all that sure where to start trying.
(In reply to comment #3) > an additional note to my previous patch: it seems like all output streams must > be directed to /dev/null for it to work, so leaving stderr open isn't any good. > > I haven't tried yet, but possibly directing stderr to an error log of some sort > would work, and keep error logs around. > > Also, I still haven't figured out why this patch works, and I'm not all that > sure where to start trying. I'm afraid this doesn't work for me. My test app, mc, still freezes everything and I can't even get X to regain control after killing mc. I also tried running setsid() in the child, but that didn't work either :( I wonder if someone really knows what is going on here. I'd like to know...
*** Bug 135 has been marked as a duplicate of this bug. ***
I tried to reproduce it in 4.4 using 'top', but nothing happened... Closing as 'fixed'...
It's fairly unavoidable unfortunately. It's a bug as old as X itself. It shows only when X is started from a console (ie not from gdm).
...
Going to close this, not much we can do about it and nobody complained since 2005.
*** Bug 15719 has been marked as a duplicate of this bug. ***