THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#705 - Awesome freezes when switching from console -> back to X
User who did this - Jim Pryor (Profjim)
----------
Hmm, this bug is really elusive.
I'm encountering it nearly all of the time, but not quite all the time. And
I've been having a hard time identifying what's needed to produce it on demand.
Also a hard time identifying which non-vanilla things on my system might be
necessary to trigger it.
Current X version is X.Org X Server 1.7.3.902 (1.7.4 RC 2), from Arch repos.
But I was seeing the bug with earlier versions of X too.
I have my own /etc/X11/{xorg.conf,xinit/xinitrc} files. But I see the bug with
the factory xinitrc file, and no xorg.conf file, too.
Current awesome version is fresh from git master:
awesome v3.4-96-g003369e (Closing In)
• Build: Jan 2 2010 14:35:10 for x86_64 by gcc version 4.4.2
(j...@vaio)
• D-Bus support: ? [that's a yes]
But I was seeing this bug with earlier versions of awesome, including the
release version 3.4.2 (and before that as well).
I normally use a lightly patched version of lua, but swapping that out for the
factory version didn't make the bug go away either.
I often use gpm in my console sessions. My suspicions are currently directed
there. However, I have seen the bug occur even when gpm is not running. At the
moment, though, if gpm is stopped, I can wait quite a while before the bug
shows up, but if I then in a console start the gpm daemon and switch back to X,
the bug immediately manifests.
$ gpm -v
gpm 1.20.6 20090209 10:59:23 +0100
$ cat /etc/conf.d/gpm
# Parameters to be passed to gpm
GPM_ARGS="-m /dev/input/mice -t ps2 -r24 -A30"
--- end /etc/conf.d/gpm ---
My input device is a AlpsPS/2 GlidePoint touchpad (on a Sony Vaio laptop), using the X
"synaptics" module. I'm using the HAL/evdev hotplugging.
One way to trigger the bug even when gpm is not running is to start a second X
session, by typing:
$ xinit awesome -- :1
That starts up a second X session fine. I'm not sure how functional this second
session is: instead of an initial terminal, I see a white square of the same
size, and I can't launch any new terminals. However, I can switch between tags
and use the awesome menu to quit this instance of Awesome. So some aspects of
the interface are working fine. If, with this second X session running, I go
back to the first X session, the bug I'm tracking immediately shows up.
I tried building awesome using the instructions at
http://awesome.naquadah.org/wiki/Debugging (at the 'v3.4.2' tag in git).
After installing, I do a startx &. Here's the relevant part of my .xsession
file:
------
# awesome/beautiful will use awsetbg to set wallpaper, so we don't need to do
anything here
# but just in case...also, this sets the cursor theme
xsetroot -solid gray42 -cursor_name left_ptr &
##xscreensaver -no-splash &
##xscreensaver-watcher & # run hooks when screen blanks/locks
export SHLVL=1
case "$1" in
xterm)
exec xterm -geometry 80x10+0+0 -name login
;;
awesome|*)
##urxvtd -q -o -f # automatically binds to lifetime of $DISPLAY
and forks to background
exec awesome
;;
esac
------
As in all these tests, my ~/.awesome/rc.lua is a symlink to
/etc/xdg/awesome/rc.lua.
Awesome starts up fine. I open some xterms and switch back to a virtual
terminal. Having built awesome in this way, it *seems* that I can switch back
and forth without triggering the freezeup.
However, suppose I now go to a console and type gdb -p `pidof awesome`; at the gdb
prompt, I type "continue", then switch back to Awesome.
If I've waited enough time (usually a second or two of waiting is too short,
but a half minute suffices, I haven't nailed this down), then there will again
be _some_ kind of freeze up. However, when I'm running Awesome under gdb, the
freeze up will be isolated to the xterms that I had started when Awesome first
started up. Those xterms get painted over with their background color and stop
responding to any input. But the desktop, tag bar, etc will continue to work
fine. I can open a new xterm and interact with it. Right-clicking on the
desktop gives me the Awesome popup menu. None of that is true when I build
Awesome without the special CFLAGS. In that case, the freezeup affects all of
Awesome, including the desktop and tag bar, and nothing responds to clicks or
keypresses. I can only do a VT switch or hit the special keys to kill the X
server.
Some more observations:
* if the freezup hasn't yet been triggered (I never leave Awesome, or
leave and return too quickly), I can stay inside Awesome for as long as I like
without any problems. I only experience it upon switching to a virtual console
and back to Awesome.
* ~/.xsession.log doesn't show anything at all interesting related to
the freezeups.
* /var/log/Xorg.0.log doesn't seem to have anything usefully related
either.
* so far as I can tell, if I change my .xsession script so that we take the
"xterm" switch rather than the "awesome" one, the freezeups never occur.
* I did "git checkout $TAG" back to TAG='v3.3.3' (I couldn't build any
further back than that with the libxcb 1.5 and xcb-util 0.3.6 I have installed.) Problem
goes back at least that far. That is, I'm no longer able to build a version of Awesome
from before the problem set in.
Sorry I can't yet pin it down more exactly. I hope this is helpful.
----------
More information can be found at the following URL:
http://awesome.naquadah.org/bugs/index.php?do=details&task_id=705#comment1704
You are receiving this message because you have requested it from the Flyspray
bugtracking system. If you did not expect this message or don't want to
receive mails in future, you can change your notification settings at the URL
shown above.
--
To unsubscribe, send mail to [email protected].
