From: George N. <gn...@cm...> - 2007-11-26 06:58:35
|
Hi all, I have been plagued with a BadWindow error in compiz-fusion on my machine for a while now. I went to the compiz developers first, and after no solution over several months, they've punted it to you. Xine works just fine using fvwm, just not in compiz-fusion. I'm running a P4 with a 6800GT nVidia using the proprietary driver in Ubuntu's Gutsy repository. Here's the error: This is xine (X11 gui) - a free video player v0.99.5cvs. (c) 2000-2006 The xine Team. xiTK WARNING(_x_error_handler:258): X error received: 'BadWindow (invalid Window parameter)' X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 20 (X_GetProperty) Resource id in failed request: 0xc00051 Serial number of failed request: 42 Current serial number in output stream: 42 It happens with all video drivers. Here was my post on the compiz-fusion forums: http://forum.compiz-fusion.org/showthread.php?t=4985 I'd greatly appreciate any help. Thanks! George |
From: Darren S. <li...@yo...> - 2007-11-26 14:30:19
|
I demand that George Nychis may or may not have written... > I have been plagued with a BadWindow error in compiz-fusion on my machine > for a while now. I went to the compiz developers first, and after no > solution over several months, they've punted it to you. Xine works just > fine using fvwm, just not in compiz-fusion. Hmm. Difference between WMs, then... > I'm running a P4 with a 6800GT nVidia using the proprietary driver in > Ubuntu's Gutsy repository. > Here's the error: > This is xine (X11 gui) - a free video player v0.99.5cvs. > (c) 2000-2006 The xine Team. > xiTK WARNING(_x_error_handler:258): X error received: 'BadWindow > (invalid Window parameter)' > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 20 (X_GetProperty) [snip] Looks like the taintware is irrelevant here... > It happens with all video drivers. These too; the "xiTK WARNING" prefix indicates that the problem is internal to xine-ui, or at least is happening while X's error handling is redirected. First, try current CVS. You should use --enable-debug when running ./configure in case the bug still happens - and if it does, read on... Enable the gui.synchronize option then quit xine (thus handling the X synchronisation stuff mentioned on that page), restart it via gdb, set a breakpoint on _x_error_handler... (gdb) run ... (gdb) bt (gdb) info locals (gdb) info args BTW, http://www.rahul.net/kenton/perrors.html provides some useful information on debugging X protocol errors. [snip] -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. I must ask you to tell me if you don't get this message. |
From: George N. <gn...@cm...> - 2007-11-28 04:35:41
|
Hi Darren, Thank you very much for the response, I greatly appreciate it! > First, try current CVS. You should use --enable-debug when running > ./configure in case the bug still happens - and if it does, read on... It still happens with the current CVS version of xine-lib and xine-ui: This is xine (X11 gui) - a free video player v0.99.6cvs-[DEBUG]. (c) 2000-2007 The xine Team. Warning! Synchronized X activated - this is very slow... xiTK WARNING(_x_error_handler:258): X error received: 'BadWindow (invalid Window parameter)' X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 20 (X_GetProperty) Resource id in failed request: 0xc000ae Serial number of failed request: 73 Current serial number in output stream: 73 > > Enable the gui.synchronize option then quit xine (thus handling the X > synchronisation stuff mentioned on that page), restart it via gdb, set a > breakpoint on _x_error_handler... > (gdb) run > ... > (gdb) bt > (gdb) info locals > (gdb) info args > Here we go: Breakpoint 1, _x_error_handler (display=0x81424c0, xevent=0xbfb98498) at xitk.c:253 253 static int _x_error_handler(Display *display, XErrorEvent *xevent) { (gdb) bt #0 _x_error_handler (display=0x81424c0, xevent=0xbfb98498) at xitk.c:253 #1 0xb7d4ebfa in _XError () from /usr/lib/libX11.so.6 #2 0xb7d506c4 in _XReply () from /usr/lib/libX11.so.6 #3 0xb7d34886 in XGetWindowProperty () from /usr/lib/libX11.so.6 #4 0x080dc37b in xitk_check_wm (display=0x81424c0) at xitk.c:501 #5 0x080df7b0 in xitk_init (display=0x81424c0, black= {pixel = 0, red = 0, green = 0, blue = 0, flags = 0 '\0', pad = 0 '\0'}, verbosity=0) at xitk.c:1880 #6 0x0805bf3c in gui_init (nfiles=0, filenames=0x813786c, window_attribute=0x812c5c8) at event.c:1664 #7 0x08070a21 in main (argc=1, argv=0xbfb99c14) at main.c:2022 (gdb) info locals buffer = '\0' <repeats 608 times>, "3⼷\000\000\000\000\000\000\000 \0003⼷\212\200\022\b\212\200\022\b\226\206¹¿ôßʷ\211\200\022\b\001\000 \000\000\030\205¹¿X]º·<\205¹¿\211\200\022\b\001\000\000\000\000\000\000\000A\205\022\b\000\000\000\000\000\000\000\000ÔÿÿÿÔÿÿÿÔÿÿÿÔÿÿÿÔÿÿÿ\217uº·\000\000\000\000\000\000\000\000ð\204¹¿\000\000\000\000\000\000\000\000\204\204¹¿\000\000\000\000\000\000\000\000\220\204¹¿\000\000\000\000\000\000\000\000\a\000\000\000\000\000\000\000Ð\205¹¿\000\000\000\000\000\000\000\000Ô\205¹¿", '\0' <repeats 24 times>, "ÿÿÿÿ\027\000\000\000\212\200\022\b"... __FUNCTION__ = "_x_error_handler" (gdb) info args display = (Display *) 0x81424c0 xevent = (XErrorEvent *) 0xbfb98498 - George |
From: Darren S. <li...@yo...> - 2007-11-28 14:42:37
Attachments:
xitk.patch
|
I demand that George Nychis may or may not have written... >> First, try current CVS. You should use --enable-debug when running >> ./configure in case the bug still happens - and if it does, read on... > It still happens with the current CVS version of xine-lib and xine-ui: [snip] > xiTK WARNING(_x_error_handler:258): X error received: 'BadWindow > (invalid Window parameter)' > X Error of failed request: BadWindow (invalid Window parameter) > Major opcode of failed request: 20 (X_GetProperty) [snip] >> Enable the gui.synchronize option then quit xine (thus handling the X >> synchronisation stuff mentioned on that page), restart it via gdb, set a >> breakpoint on _x_error_handler... >> (gdb) run >> ... >> (gdb) bt >> (gdb) info locals >> (gdb) info args > Here we go: > Breakpoint 1, _x_error_handler (display=0x81424c0, xevent=0xbfb98498) > at xitk.c:253 > 253 static int _x_error_handler(Display *display, XErrorEvent *xevent) { > (gdb) bt > #0 _x_error_handler (display=0x81424c0, xevent=0xbfb98498) at xitk.c:253 > #1 0xb7d4ebfa in _XError () from /usr/lib/libX11.so.6 > #2 0xb7d506c4 in _XReply () from /usr/lib/libX11.so.6 > #3 0xb7d34886 in XGetWindowProperty () from /usr/lib/libX11.so.6 > #4 0x080dc37b in xitk_check_wm (display=0x81424c0) at xitk.c:501 [snip] > (gdb) info locals [snip] There should have been an "up 4" before that (to get to the right stack frame) but it's unnecessary - the backtrace is enough and is pointing at the check for a GNOME-compliant window manager. (The X error doesn't happen here; but then I'm using xfwm4.) That said, I've just noticed a type mismatch - try the attached patch (which should be committed anyway for correctness). -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. I'm not under the alkafluence of inkahol that some thinkle peep I am. |
From: George N. <gn...@cm...> - 2007-11-28 15:04:03
|
> I demand that George Nychis may or may not have written... > You're very demanding ;) > There should have been an "up 4" before that (to get to the right stack > frame) but it's unnecessary - the backtrace is enough and is pointing at the > check for a GNOME-compliant window manager. (The X error doesn't happen here; > but then I'm using xfwm4.) > > That said, I've just noticed a type mismatch - try the attached patch (which > should be committed anyway for correctness). > Thanks for the patch. I still am receiving the error, so I'm going to properly run GDB this time :) Breakpoint 1, _x_error_handler (display=0x81424c0, xevent=0xbfbafc98) at xitk.c:253 253 static int _x_error_handler(Display *display, XErrorEvent *xevent) { (gdb) bt #0 _x_error_handler (display=0x81424c0, xevent=0xbfbafc98) at xitk.c:253 #1 0xb7da6bfa in _XError () from /usr/lib/libX11.so.6 #2 0xb7da86c4 in _XReply () from /usr/lib/libX11.so.6 #3 0xb7d8c886 in XGetWindowProperty () from /usr/lib/libX11.so.6 #4 0x080dc37b in xitk_check_wm (display=0x81424c0) at xitk.c:501 #5 0x080df7b0 in xitk_init (display=0x81424c0, black= {pixel = 0, red = 0, green = 0, blue = 0, flags = 0 '\0', pad = 0 '\0'}, verbosity=0) at xitk.c:1880 #6 0x0805bf3c in gui_init (nfiles=0, filenames=0x813786c, window_attribute=0x812c5c8) at event.c:1664 #7 0x08070a21 in main (argc=1, argv=0xbfbb1414) at main.c:2022 ------------------------ (gdb) up 4 #4 0x080dc37b in xitk_check_wm (display=0x81424c0) at xitk.c:501 501 status = XGetWindowProperty(display, win_id, atom, 0, ------------------------ (gdb) info locals prop_return2 = (unsigned char *) 0x0 win_id = 12583086 nitems_return = 1 type_return = 6 status = 135429921 prop_return = (unsigned char *) 0x814d0f0 "®" bytes_after_return = 0 format_return = 32 atom = 346 type = 0 wm_name = 0x0 ------------------------ (gdb) info args display = (Display *) 0x81424c0 Hope this helps! Again, I appreciate it. - George |
From: Darren S. <li...@yo...> - 2007-11-28 15:52:26
|
I demand that George Nychis may or may not have written... >> I demand that George Nychis may or may not have written... > You're very demanding ;) I demand that I may or may not be demanding. ;-) >> There should have been an "up 4" before that (to get to the right stack >> frame) but it's unnecessary - the backtrace is enough and is pointing at >> the check for a GNOME-compliant window manager. (The X error doesn't >> happen here; but then I'm using xfwm4.) >> That said, I've just noticed a type mismatch - try the attached patch >> (which should be committed anyway for correctness). > Thanks for the patch. I still am receiving the error, Right... I wasn't really expecting it to help anywhere but 64-bit big-endian. > so I'm going to properly run GDB this time :) > Breakpoint 1, _x_error_handler (display=0x81424c0, xevent=0xbfbafc98) > at xitk.c:253 > 253 static int _x_error_handler(Display *display, XErrorEvent *xevent) { > (gdb) bt > #0 _x_error_handler (display=0x81424c0, xevent=0xbfbafc98) at xitk.c:253 > #1 0xb7da6bfa in _XError () from /usr/lib/libX11.so.6 > #2 0xb7da86c4 in _XReply () from /usr/lib/libX11.so.6 > #3 0xb7d8c886 in XGetWindowProperty () from /usr/lib/libX11.so.6 > #4 0x080dc37b in xitk_check_wm (display=0x81424c0) at xitk.c:501 [snip] > ------------------------ > (gdb) up 4 > #4 0x080dc37b in xitk_check_wm (display=0x81424c0) at xitk.c:501 > 501 status = XGetWindowProperty(display, win_id, atom, 0, > ------------------------ > (gdb) info locals > prop_return2 = (unsigned char *) 0x0 > win_id = 12583086 [snip] > Hope this helps! Again, I appreciate it. (gdb) shell xwininfo -id 12583086 (You'll need to alter that value to match the reported value of win_id, which comes from reading _WIN_SUPPORTING_WM_CHECK from the default root window for the display.) I'm expecting xwininfo to return an error, and I think that it's worth giving the compiz people a bit more information. I think that this problem is their responsibility... -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Procrastination should never be left until tomorrow. |
From: George N. <gn...@cm...> - 2007-12-04 00:33:39
|
Darren Salt wrote: > (You'll need to alter that value to match the reported value of win_id, which > comes from reading _WIN_SUPPORTING_WM_CHECK from the default root window for > the display.) > > I'm expecting xwininfo to return an error, and I think that it's worth giving > the compiz people a bit more information. I think that this problem is their > responsibility... > So I handed this over to the compiz guys and they say a patch was released at one point for xine to possibly take care of a stale value left over from xfwm4. I tried searching for it and can't find it. Here is my compiz-fusion bug report: http://bugs.opencompositing.org/show_bug.cgi?id=647 Might anyone know where this patch went? - George |
From: Darren S. <li...@yo...> - 2007-12-05 03:01:15
|
I demand that George Nychis may or may not have written... > Darren Salt wrote: >> (You'll need to alter that value to match the reported value of win_id, >> which comes from reading _WIN_SUPPORTING_WM_CHECK from the default root >> window for the display.) >> I'm expecting xwininfo to return an error, and I think that it's worth >> giving the compiz people a bit more information. I think that this >> problem is their responsibility... > So I handed this over to the compiz guys and they say a patch was released > at one point for xine to possibly take care of a stale value left over from > xfwm4. I tried searching for it and can't find it. [snip] > Might anyone know where this patch went? http://sourceforge.net/mailarchive/message.php?msg_name=E1Iye9T-0007Dj-5I%40sc8-pr-cvs10.sourceforge.net -- | Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. Modern man is the missing link between apes and human beings. |
From: George N. <gn...@cm...> - 2007-12-05 05:01:44
|
Darren Salt wrote: > I demand that George Nychis may or may not have written... > >> Darren Salt wrote: >>> (You'll need to alter that value to match the reported value of win_id, >>> which comes from reading _WIN_SUPPORTING_WM_CHECK from the default root >>> window for the display.) > >>> I'm expecting xwininfo to return an error, and I think that it's worth >>> giving the compiz people a bit more information. I think that this >>> problem is their responsibility... > >> So I handed this over to the compiz guys and they say a patch was released >> at one point for xine to possibly take care of a stale value left over from >> xfwm4. I tried searching for it and can't find it. > [snip] >> Might anyone know where this patch went? > > http://sourceforge.net/mailarchive/message.php?msg_name=E1Iye9T-0007Dj-5I%40sc8-pr-cvs10.sourceforge.net > Thank you!! I can finally enjoy the greatness of xine again :) I greatly appreciate it. - George |