Bug 295875 - oxygen gtk2-engine application crash: BadWindow (invalid Window parameter) X Window system error
Summary: oxygen gtk2-engine application crash: BadWindow (invalid Window parameter) X ...
Status: CLOSED FIXED
Alias: None
Product: Oxygen
Classification: Unclassified
Component: gtk2-engine (show other bugs)
Version: unspecified
Platform: Archlinux Packages Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL:
Keywords:
: 295966 296082 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-12 22:20 UTC by Federico Stafforini
Modified: 2012-05-15 04:06 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Federico Stafforini 2012-03-12 22:20:00 UTC
Running wingide 4.1.3 with oxygen-gtk2theme selected will crash every time certain dialogs are closed (for instance start/continue or project properties).

This happens since 1.2.2 and onwards, also with today's git version. It does not happen in oxygen-gtk2 1.2.0. 

No other theme causes this, the program works fine under all other gtk themes.
This happens with wingide professional 4.1.3. So far I haven't found  any other dialog in another app where this happens (but I don't use many gtk2 apps).

Console output:
    The program wing.py received an X Window System error.
    This probably reflects a bug in the program.
    The error was BadWindow (invalid Window parameter).
      (Details: serial 31563 error_code 3 request_code 152 minor_code 3)
      (Note to programmers: normally, X errors are reported asynchronously;
       that is, you will receive the error a while after causing it.
       To debug your program, run it with the --sync command line
       option to change this behavior. You can then get a meaningful
       backtrace from your debugger if you break on the gdk_x_error() function.)
Comment 1 Federico Stafforini 2012-03-12 22:51:30 UTC
This happens under x86-64 architecture. Could not reproduce bug using 32 bit libs and apps on the same system.
Comment 2 Ruslan Kabatsayev 2012-03-13 05:52:31 UTC
Please use git-bisect to find the guilty commit.
Comment 3 Hugo Pereira Da Costa 2012-03-14 08:47:36 UTC
*** Bug 295966 has been marked as a duplicate of this bug. ***
Comment 4 Hugo Pereira Da Costa 2012-03-14 08:52:17 UTC
@Ruslan, others
I suspect fe399f97bd478a33241a5a4213498072292ce841
To be the guilty guy. (basically reverting compositing on a window that has been already destroyed).
Can someone that experience the bug 
1/ get oxygen gtk from source
   git clone git://anongit.kde.org/oxygen-gtk
2/ checkout before the commit before
   git checkout fe399f97bd478a33241a5a4213498072292ce841^
(don't forget the "^")
3/ compile and see if the bug is still there
4/ checkout the revision:    git checkout fe399f97bd478a33241a5a4213498072292ce841
5/ compile and see if the bug is here.
Comment 5 Hugo Pereira Da Costa 2012-03-14 09:06:18 UTC
@Ruslan
Note: if this indeed is the bug, the fix (that does not break gtk-chtheme) would be either
- find a way to check the validity of the window before reverting compositing (might be difficult)
- not reverting compositing in destructor (disconnect)
- revert everything manually in theme exit (for lxappearance or gth-chtheme)
I sure can work on that but need confirmation first.
Comment 6 Ruslan Kabatsayev 2012-03-14 10:21:51 UTC
(In reply to comment #5)
If you mean that the problem is our gdk_window_set_composited(window,_initiallyComposited), then it's strange that we get BadWindow after GDK_IS_WINDOW returns true.
Also, I'd rather see which request fails using --sync option to GTK program and breaking on gdk_x_error().
Comment 7 Hugo Pereira Da Costa 2012-03-14 10:23:47 UTC
@ruslan,
might be an underlying gtk issue
GdkWindow still exists, but underlying X window is gone (unmapped or smthing like that)
then crash when gdk_window_set_composite (or whatever the name) try access the X window to change the "composite" flag ... something like that.
(iirc, I've seen this happen for other calls)
Comment 8 Ruslan Kabatsayev 2012-03-14 11:03:13 UTC
(In reply to comment #7)
It seems you might be right. There's a gdk_window_is_destroyed() function, so maybe we should check it before setting composite state.
Comment 9 Ruslan Kabatsayev 2012-03-14 11:05:24 UTC
Git commit d6c4de90902a005fc14e55c1789bec276dbfcdf0 by Ruslan Kabatsayev.
Committed on 14/03/2012 at 12:04.
Pushed by kabatsayev into branch '1.2'.

Check if GdkWindow is destroyed before restoring composited state

M  +1    -1    src/animations/oxygeninnershadowdata.cpp

http://commits.kde.org/oxygen-gtk/d6c4de90902a005fc14e55c1789bec276dbfcdf0
Comment 10 Hugo Pereira Da Costa 2012-03-14 11:06:49 UTC
@ruslan
sounds good.
Although I'd like to have confirmation for comment #4
Anyone ?

Thanks for the commit anyway ! (can't hurt)
Comment 11 Hugo Pereira Da Costa 2012-03-14 11:27:21 UTC
@Ruslan,
good news, 
without your commit (forward ported to gtk3), gtk3-demo was crashing at exit (likely with the same issue), and is not anymore. Most likely your fix works !
Comment 12 Ruslan Kabatsayev 2012-03-14 11:36:38 UTC
OK, I mark this fixed. If it appears to not be, please reopen.
Comment 13 Federico Stafforini 2012-03-17 13:23:03 UTC
I confirm the original issue is fixed. Thanks!
Comment 14 Ruslan Kabatsayev 2012-03-17 21:51:15 UTC
*** Bug 296082 has been marked as a duplicate of this bug. ***