GNOME Bugzilla – Bug 501842
System tray icons on an argb visual results in crash
Last modified: 2008-02-03 01:20:56 UTC
Steps to reproduce: 1. Start a systray container that uses an argb visual (e.g. plasma in kde4) 2. Start any gtk+ application that uses a StatusIcon 3. Stack trace:
+ Trace 180853
Other information: Unfortunately this bug in gtk makes every systray using gtk app unusable in KDE4. The call that triggers the bug appears to be a call to XSetWindowBackgroundPixmap, which can be seen in this file here: http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/applets/systemtray/systemtraycontainer.cpp?view=markup
I don't consider the code you pointed to at all legitimate. The background color or pixmap of a window is the business of the creator of the window, and nobody else. But even so, it's not clear to me how that would cause the crash you report ... what's the actual X error? More information should be printed to stderr.
> I don't consider the code you pointed to at all legitimate be that as it may, that's really neither here nor there. this result is a crash that is easily caused by an external app; if it was simply a matter of the code causing some non-critical misbehaviour (e.g. gtk+ decides this is illegitimate, ignores it or otherwise handles it gracefully) it wouldn't be an issue. > The background color or pixmap of a window is the business of the creator of > the window as long as we (x11 envs) insist on abusing xembed for things like systray icons, we need to live with the fact that while this is a nice theory we are making it difficult to actually practice. > it's not clear to me how that would cause the crash you report ... > what's the actual X error? More information should be printed to stderr. The program 'rhythmbox' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 615 error_code 8 request_code 2 minor_code 0) (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.) i used rhythmbox in the above example, but it happens with any gtk+ systray using app that's been tested thus far. hope the above helps a bit more =)
This may be relevant: http://lists.freedesktop.org/archives/xorg/2005-January/005790.html I think if your system tray has a different visual than the contained tray icons, and the contained icons set ParentRelative, that is going to break (at least, if you have a back pixmap set on the tray). According to that old thread, window managers were working around this by copying the child window's visual when creating a frame. A systray could do that too, if it has a separate socket window per child anyway. It's a theory anyway...
Well, XDestroyWindow() on a window of a random app will cause the app to crash as well... But I think Havoc may have a good idea ... that it's not the code you pointed to that is causing the crash, but rather GTK+ is *defeating* that workaround by setting the background back to ParentRelative after the reparent. Though I'd consider it an X bug if setting a ParentRelative background on a RGB window with an ARGB background causes a BadMatch. ParentRelative is, as I recall, best effort.
BTW, Havoc pointed out that the reliable workaround that KDE could take, that doesn't depend on the app not changing its background again, would be to create a parent window for the icon matching the icon's visual, if the icon's visual doesn't match the tray. The appearance will be identical... a box around the icon either way... and it will work: - Without regard to X server version - Without regard to what the icon does in the future with its background pixmap. - Without regard to GTK+ version (I don't know how we would "fix" this in GTK+ other than special casing running in the KDE tray inside GDK, but even if we did, you'd still have to worry about old versions of GTK+)
The problem has been worked around in KDE. Feel free to close this bugreport if you want.
Just tested today, applications crashes in GNOME when using rgba colormap. We should really fix this.
Created attachment 104282 [details] Force RGBA colormap, for TESTING Compile the library, then run in terminal: LD_PRELOAD=./rgbahack.so liferea (liferea, exaile, banshee and any system-tray aware applications)
Andrea: You can't just change the default color map to something an application isn't expecting and expect it to work. Unrelated to this issue in any case. I'm going to resolve this NOTABUG. It's certainly legitimate for a tray icon to change it's background pixmap to parent relative if it wants to.
@9: But why this happens only with GTK apps? Why there isn't a check that if finds ParentRelative NULL (or whatelse... what happenes to make the crash?) sets it to a saner value? (or just force an rgb colormap). OT: what we should to when we set a default rgba colormap in an application with a tray? If GTK+ provides a feature (RGBA) then it must be 100% working...