When running recent (as of 8/16/04) xcompmgr and xorg-cvs, after a varrying period of time the server appears to become locked in that no screen updates are apparent and windows don't appear to respond to mouse or keyboard events. In fact windows do respond to the mouse and keyboard (as made evident by the changing of the x cursor to indicate when it is over the title bar or border of a window) but the screen does not reflect these window movements. The screen image remains unchanged/static i.e. windows do not appear to have moved, it's still as a painted ship on a painted sea. :P Frequently alt-tabbing between windows while xcompmgr -c is running seems to initiate this bug more quickly though it will always happen in time. Switching to a vt and killing xcompmgr restores the server to a functional state. Also if xcompmgr was launced from a terminal within the server ctrl-c will return the server to a functional state (it's just a little hard to do that when you can't see what window has focus). specs: Pentium 4 2.4ghz (laptop w/ desktop cpu) 648mb system ram FC2 (severly updated) ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 02) 64mb Linux ruined 2.6.7-1.437.1.ll.rhfc2.ccrma #1 Thu Jun 17 10:45:42 PDT 2004 i686 i686 i386 GNU/Linux xorg-cvs from 08-16-04 xcompmgr from 08-16-04 and prior Dri enabled and functional Section "Device" Identifier "** ATI Radeon (generic) [radeon]" Driver "radeon" Option "RenderAccel" "On" Option "AGPFastWrite" "On" Option "EnablePageFlip" "On" EndSection Section "Module" Load "dbe" # Double buffer extension SubSection "extmod" Option "omit xfree86-dga" # don't initialise the DGA extension EndSubSection Load "type1" Load "speedo" Load "freetype" Load "glx" Load "dri" EndSection
One more detail, when this occurs xcompmgr consumes > 90% cpu.
Using a very old xcompmgr (from around June 11, 2004) from the kdrive tree I'm unable to replicate. Xcompmgr crashes frequently but there have been no screen freezes. So my guess this is an xcompmgr bug?
I have some steps that causes xcompmgr to freeze in just the way this bug describes. If I start with step 2 below I just get error messages, but if I first take the screenshot the following steps always seams to cause xcompmgr to hang also. Weird, I know;-) Try it a few times it it doesn't hang right away. 1) Take a screenshot with "import -window root test.png" 2) Open it with eog (Eye of GNOME). It *must* be in eog, no other image viewer. 3) Drag eog it to the middle of the screen and close the window. Result: xcompmgr prints out error messages and programs stops accepting clicks. Sometimes the screen is corrupted. I attached gdb to xcompmgr one of the times when I reproduced this and got the following: find_win (dpy=0x804e008, id=12601204) at xcompmgr.c:616 616 if (w->id == id) (gdb) bt #0 find_win (dpy=0x804e008, id=12601204) at xcompmgr.c:616 #1 0x0804b371 in unmap_win (dpy=0x804e008, id=134577024, fade=1) at xcompmgr.c:1105 #2 0x0804c3a7 in main (argc=-1073743552, argv=0x2) at xcompmgr.c:1792 xcompmgr also prints out error messages of the type "error 9 request 158 minor 1 serial 10154".
Periodically instead of freezing the screen xcompmgr just segfaults. I finally figured out how to make it dump core. I ran gdb on the core file and this is what bt reports: #0 find_win (dpy=0x10, id=10495522) at xcompmgr.c:616 #1 0x0804a734 in map_win (dpy=0x10, id=10495522, sequence=2157, fade=1) at xcompmgr.c:1028 #2 0x0804b79e in main (argc=134537224, argv=0x6) at xcompmgr.c:1789
There's a pattern to the errors that xcompmgr prints when the screen freezes: [ryanpg@ruined ryanpg]$ xcompmgr -c error 9 request 156 minor 1 serial 4098 error 3 request 2 minor 0 serial 4099 error 3 request 20 minor 0 serial 4100 [ryanpg@ruined ryanpg]$ xcompmgr -c error 9 request 156 minor 1 serial 739 error 3 request 2 minor 0 serial 740 error 3 request 20 minor 0 serial 741 error 9 request 156 minor 1 serial 763 error 3 request 2 minor 0 serial 764 error 3 request 20 minor 0 serial 765 [ryanpg@ruined ryanpg]$ xcompmgr -c error 9 request 156 minor 1 serial 11057 error 3 request 2 minor 0 serial 11058 error 3 request 20 minor 0 serial 11059 [ryanpg@ruined ryanpg]$ xcompmgr -c error 9 request 156 minor 1 serial 27268 error 3 request 2 minor 0 serial 27269 error 3 request 20 minor 0 serial 27270 [ryanpg@ruined ryanpg]$ xcompmgr -c error 9 request 156 minor 1 serial 729 error 3 request 2 minor 0 serial 730 error 3 request 20 minor 0 serial 731 [ryanpg@ruined ryanpg]$ xcompmgr -c error 9 request 156 minor 1 serial 209720 error 3 request 2 minor 0 serial 209721 error 3 request 20 minor 0 serial 209722
I have been having the same issues using the RC2 build of xorg and a Nvidia GeForce4Go card with the Nvidia binary drivers (6106) on debian unstable. Upon investigating I have found that the problem is that the window list (pointed to by the global list) was being corrupted when the displayed errors occurred and an item would be added to the list that would point to itself (hence the lockup as the repaint_all loop goes around forever). After trying various things I have noticed that if I add a small delay into the add_win function between the call to XSelectInput() and the call to get_opacity_prop() (probably the XGetWindowProperty() in get_opacity_prop()) the corruption stops happening. I found this when I was trying to trace where the errors where occurring and I added a printf between the two calls and it fixed the problem. I have since removed all the debugging and added a usleep(10) and the problem no longer occurres, though you still get the errors. Looks like there is some interaction taking place either in the Xlib or between the Xlib and the xcompmgr code that is causing the issue.
Created attachment 691 [details] [review] adds usleep(10); This stops the "screen freezing" thanks to Phillip Sessions efforts. Probably covers up the real source of the problem (errors leading to the duplicate name loop).
I am experiencing the same problem with the same hardware, and xorg-cvs and xcompmgr from sept 7, 2004. The patch did allow xcompmgr to run, but it is spewing out simialr error messages: steve@doolittle:/usr/src/xcompmgr$ ./xcompmgr -n error 9 request 158 minor 1 serial 1860 error 3 request 2 minor 0 serial 1861 error 3 request 20 minor 0 serial 1862 error 9 request 158 minor 1 serial 2183 error 3 request 2 minor 0 serial 2184 error 3 request 20 minor 0 serial 2185 error 9 request 158 minor 1 serial 2281 error 3 request 2 minor 0 serial 2282 error 3 request 20 minor 0 serial 2283 error 9 request 158 minor 1 serial 6281 error 3 request 2 minor 0 serial 6282 error 3 request 20 minor 0 serial 6283 error 9 request 158 minor 1 serial 9806 error 3 request 2 minor 0 serial 9807 error 3 request 20 minor 0 serial 9808 error 9 request 158 minor 1 serial 11714 error 3 request 2 minor 0 serial 11715 error 3 request 20 minor 0 serial 11716 error 9 request 158 minor 1 serial 15477 error 3 request 2 minor 0 serial 15478 error 3 request 20 minor 0 serial 15479 error 9 request 158 minor 1 serial 24756 error 3 request 2 minor 0 serial 24757 error 3 request 20 minor 0 serial 24758 error 9 request 158 minor 1 serial 31493 error 3 request 2 minor 0 serial 31494 error 3 request 20 minor 0 serial 31495 error 9 request 158 minor 1 serial 38979 error 3 request 2 minor 0 serial 38980 error 3 request 20 minor 0 serial 38981 error 9 request 158 minor 1 serial 46903 error 3 request 2 minor 0 serial 46904 error 3 request 20 minor 0 serial 46905 error 9 request 158 minor 1 serial 54224 error 3 request 2 minor 0 serial 54225 ...
Hi there, same thing here with nvidia triple head setup (OK this IS an unusual setup). I use a GF FX5900XT for two displays, and a TNT1/PCI for the third one. System is Gentoo Linux (mostly stable except nvidia-kernel and xorg-x11-6.8 which is not yet marked as stable in the gentoo tree, gnome 2.6). This happens immediatly after starting xcompmgr: bash-2.05b$ xcompmgr -c & [1] 6893 bash-2.05b$ bash-2.05b$ error 9 request 158 minor 4 serial 477 error 9 request 158 minor 4 serial 487 error 9 request 158 minor 4 serial 497 error 9 request 158 minor 4 serial 507 error 9 request 158 minor 4 serial 517 error 9 request 158 minor 4 serial 527 error 9 request 158 minor 4 serial 537 error 9 request 158 minor 4 serial 547 error 9 request 158 minor 4 serial 557 When I use one head instead of three (GF-FX main screen), system and xcompmgr works well together, with shadows and transparencies; for three heads all windows are gone, only background is drawn and the window shadows. Mouse cursor interacts with window borders. Killing xcompmgr "fixes" the problem. I think this may be connected to this problem, so I don't open a new bug.
I see the same problem on Xorg 6.8.0 release with an Radeon 9500pro with both the fglrx and radeon drivers. Here are the errors I get from xcompmgr: error 3 request 15 minor 0 serial 29718 error 9 request 155 minor 1 serial 29788 error 3 request 20 minor 0 serial 29789 error 3 request 20 minor 0 serial 29790 error 3 request 15 minor 0 serial 29791 error 9 request 155 minor 1 serial 30059 error 3 request 20 minor 0 serial 30060 error 3 request 20 minor 0 serial 30061 Applying the usleep() patch makes things better. I also notice some artifacts when I move the window: when I move a window to the left some "leftover" part of the border doesn't get cleared on the right side. This only happens when moving the window from right to left, not when I move it from left to right.
The changes introduced in revision 1.27, which add a couple of nice effects and fix the window-is-invisible-when-remapped-after-a-fade problem, restrucuture the code such that this usleep hack doesn't work anymore. The XSelectInput() call is moved to map_win from add_win so everything's changed.
just got the latest CVS, still the same problem here :( Anything I could do to help finding what the problem is? Debugging or enhanced error message stuff? I tried several combinations of parameters, but I was unable to get it working. It always a) gives those errors and screen is freezed b) or does nothing (no shadows/transparency) I really neeeed this ;)
Is this still an issue for people with normal setups? If so, can anyone give me a sure-fire method of producing the problem in KDE (I'd rather not install Gnome unless I have to)? Lars: I'd like to solve your problem, but I don't have any triple (or even dual) screen setups to test on. :) Does anyone have xcompmgr working on dual screens at all? I don't really know how Xinerama works, but seeing as xcompmgr only draws to the default root window, I wouldn't bet that it'd work with multiple displays.
I still get the same kind of errors; error 3 request 15 minor 0 serial 151495 error 3 request 2 minor 0 serial 151496 error 3 request 2 minor 0 serial 151507 I haven't had the "screen lockup" issue but xcompmgr does segfault. These errors occur when I alt-tab or occasionally when I drag an icon. I have 09/22/04 xcompmgr and gnome 2.6.
Yes, I get the errors as well, usually related to window destruction. I've been trying to find the source without too much success. However, I think the restructuring of the code (along with ajax fixing a blunder of mine) may have eliminated the screen freeze problem, as I haven't seen it in a while. I don't think the error messages are related (and they may in fact be mostly benign). Segfaults are another matter. If you can, run xcompmgr in gdb (or use it to examine the core dumps) and see if you can get any kind of consistent looking traces and post a new bug with them (note: running xcompmgr in gdb _will_ make your screen appear to freeze in the same way when it crashes, since it doesn't give back the screen. You might want to run gdb in a separate virtual terminal with "xcompmgr -d :0" so that you can alt-F? to the console when xcompmgr segfaults and kill it for real) and I'll try to track down the problem.
this hasn't been observed in ages. if xcompmgr still freezes the screen, please reopen. if other bugs are observer please file new ones.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.