After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 501842 - System tray icons on an argb visual results in crash
System tray icons on an argb visual results in crash
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Widget: Other
2.10.x
Other All
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-12-05 18:11 UTC by Aaron Seigo
Modified: 2008-02-03 01:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Force RGBA colormap, for TESTING (1.02 KB, application/x-bzip)
2008-02-02 22:36 UTC, Andrea Cimitan
Details

Description Aaron Seigo 2007-12-05 18:11:42 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:
  • #0 gdk_x_error
    at gdkmain-x11.c line 613
  • #1 _XError
    from /usr/lib/libX11.so.6
  • #2 _XReply
    from /usr/lib/libX11.so.6
  • #3 XSync
    from /usr/lib/libX11.so.6
  • #4 ??
    from /usr/lib/libX11.so.6
  • #5 XSetWindowBackgroundPixmap
    from /usr/lib/libX11.so.6
  • #6 _gdk_x11_window_tmp_reset_bg
    at gdkwindow-x11.c line 250
  • #7 _gdk_window_move_resize_child
    at gdkgeometry-x11.c line 724
  • #8 IA__gdk_window_move_resize
    at gdkwindow-x11.c line 1787
  • #9 gtk_event_box_size_allocate
    at gtkeventbox.c line 542
  • #10 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #11 ??
    from /usr/lib/libgobject-2.0.so.0
  • #12 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #13 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #14 IA__gtk_widget_size_allocate
    at gtkwidget.c line 3063
  • #15 gtk_window_size_allocate
    at gtkwindow.c line 4471
  • #16 gtk_plug_size_allocate
    at gtkplug.c line 623
  • #17 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #18 ??
    from /usr/lib/libgobject-2.0.so.0
  • #19 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #20 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #21 IA__gtk_widget_size_allocate
    at gtkwidget.c line 3063
  • #22 gtk_window_check_resize
    at gtkwindow.c line 5700
  • #23 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #24 ??
    from /usr/lib/libgobject-2.0.so.0
  • #23 g_closure_invoke
    from /usr/lib/libgobject-2.0.so.0
  • #24 ??
    from /usr/lib/libgobject-2.0.so.0
  • #25 g_signal_emit_valist
    from /usr/lib/libgobject-2.0.so.0
  • #26 g_signal_emit
    from /usr/lib/libgobject-2.0.so.0
  • #27 gtk_container_idle_sizer
    at gtkcontainer.c line 1110
  • #28 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #29 ??
    from /usr/lib/libglib-2.0.so.0
  • #30 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #31 IA__gtk_main
    at gtkmain.c line 1177
  • #32 main


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
Comment 1 Owen Taylor 2007-12-05 18:40:54 UTC
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.

Comment 2 Aaron Seigo 2007-12-05 18:56:17 UTC
> 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 =)
Comment 3 Havoc Pennington 2007-12-05 19:32:58 UTC
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...
Comment 4 Owen Taylor 2007-12-05 20:26:49 UTC
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.
Comment 5 Owen Taylor 2007-12-08 17:02:10 UTC
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+)
Comment 6 Lubos Lunak 2008-01-07 11:21:06 UTC
The problem has been worked around in KDE. Feel free to close this bugreport if you want.
Comment 7 Andrea Cimitan 2008-02-02 22:31:01 UTC
Just tested today, applications crashes in GNOME when using rgba colormap.
We should really fix this.
Comment 8 Andrea Cimitan 2008-02-02 22:36:35 UTC
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)
Comment 9 Owen Taylor 2008-02-03 01:03:07 UTC
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.


Comment 10 Andrea Cimitan 2008-02-03 01:20:56 UTC
@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...