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 523328 - infinite loop caused by setting color scheme
infinite loop caused by setting color scheme
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.12.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
: 514399 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-03-19 09:36 UTC by Sebastien Bacher
Modified: 2013-02-13 04:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Sebastien Bacher 2008-03-19 09:36:10 UTC
The bug has been described on https://bugs.launchpad.net/bugs/147045

"1. If .gtkrc-2.0 exists but is empty, the bug does not appear.
2. If I launch gnome-appearance-properties with a non-empty .gtkrc-2.0 file, the bug triggers every time. Once it is triggered, if I remove the .gtkrc-2.0 file or empty it while g-a-p is still running (either the window is still open or I closed it but g-a-p is still running), g-a-p reacts almost immediately and the CPU goes back to 0%.
3. If I launch g-a-p with no (or an empty) .gtkrc-2.0 file, the bug is not triggered, even if I create the file once it is running.

http://launchpadlibrarian.net/11109694/g-a-p.trace
Fragment of a trace repeated by g-a-p when the bug is triggered. (6.5 KiB, text/plain)

I've been able to narrow the problem a little more. It seems the actual line in my .gtkrc-2.0 which causes the problem is the following:

include "/usr/share/themes/Clearlooks/gtk-2.0/gtkrc"

If I start g-a-p with a .gtkrc-2.0 containing this line (alone or with the rest of my original file), the bugs triggers every time, and the CPU goes to 100%. If I overwrite the .gtkrc-2.0 file while g-a-p is "hung" with a version without the line, the CPU goes back to ~0%, and g-a-p exits correctly.

I've attached strace to g-a-p while it is hung, at it seems caught in a loop. I've attached the fragment of the trace which is repeated endlessly (I don't know which line can be considered the beginning of the loop though)."
Comment 1 Jens Granseuer 2008-03-19 19:43:03 UTC
Doing that apparently creates an infinite loop in gtk. Here's an arbitrary backtrace from such a situation. The g-a-p thumbnailer never returns from the g_object_set call. Not sure if there's something we can do to avoid that (apart from setting a timeout on the thumbnailer).

  • #0 g_free
    at gmem.c line 186
  • #1 gtk_rc_parse_statement
    at gtkrc.c line 2904
  • #2 gtk_rc_parse_any
    at gtkrc.c line 2251
  • #3 gtk_rc_context_parse_one_file
    at gtkrc.c line 1012
  • #4 gtk_rc_context_parse_file
    at gtkrc.c line 1078
  • #5 parse_include_file
    at gtkrc.c line 2860
  • #6 gtk_rc_parse_statement
    at gtkrc.c line 2888
  • #7 gtk_rc_parse_any
    at gtkrc.c line 2251
  • #8 gtk_rc_context_parse_one_file
    at gtkrc.c line 1012
  • #9 gtk_rc_context_parse_file
    at gtkrc.c line 1078
  • #10 gtk_rc_parse_default_files
    at gtkrc.c line 841
  • #11 gtk_rc_reparse_all_for_settings
    at gtkrc.c line 1786
  • #12 gtk_rc_color_hash_changed
    at gtkrc.c line 667
  • #13 g_cclosure_marshal_VOID__PARAM
    at gmarshal.c line 531
  • #14 g_closure_invoke
    at gclosure.c line 490
  • #15 signal_emit_unlocked_R
    at gsignal.c line 2440
  • #16 g_signal_emit_valist
    at gsignal.c line 2199
  • #17 g_signal_emit
    at gsignal.c line 2243
  • #18 g_object_dispatch_properties_changed
    at gobject.c line 563
  • #19 g_object_notify_dispatcher
    at gobject.c line 245
  • #20 g_object_notify_queue_thaw
    at gobjectnotifyqueue.c line 123
  • #21 g_object_set_valist
    at gobject.c line 1136
  • #22 g_object_set
    at gobject.c line 1212
  • #23 create_meta_theme_pixbuf
    at theme-thumbnail.c line 265
  • #24 message_from_capplet
    at theme-thumbnail.c line 710

Comment 2 Jens Granseuer 2008-03-19 22:15:14 UTC
Had a little chat with benzea on IRC, and it turns out that...

(23:03:52) benzea: ok, it is the color scheme stuff causing it I guess
(23:04:43) benzea: something along the line, theme sets the color scheme, then clearlooks is included, clearlooks sets the color scheme, gtk+ decides to reparse everything as the color scheme changed
(23:05:43) fizz: that'd certainly explain it
(23:08:00) benzea: yup, that is the problem
(23:09:05) benzea: just putting gtk-color-scheme="fg_color:#ff0000" into .gtkrc-2.0 is enough
(23:09:31) benzea: (it needs to be one of the colors that the theme uses)

So, moving to gtk.
Comment 3 Benjamin Berg 2008-03-19 23:20:45 UTC
The problem happens as soon as the application sets the gkt-color-scheme property. This seems to cause bogus change notifications.

To put the following lines into the .gtkrc-2.0 (as these are two, the theme can be raleigh; the color values need to be different):
gtk-color-scheme="blub:#ff0000"
gtk-color-scheme="blub:#00ff00"

And the following C file (test.c). It does not matter what color is set here, it can be the same, but also a different one.
/* gcc -o test test.c `pkg-config --cflags --libs gtk+-2.0` */
#include <gtk/gtk.h>
int main(int argc, char **argv)
{
  GtkSettings *settings;
  gtk_init (&argc, &argv);
  
  settings = gtk_settings_get_default ();
  g_object_set (settings, "gtk-color-scheme", "asdf:#ff0", NULL);
  
  gtk_main();
}
Comment 4 Jens Granseuer 2008-09-16 18:02:42 UTC
*** Bug 514399 has been marked as a duplicate of this bug. ***
Comment 5 Matthias Clasen 2008-09-28 04:12:20 UTC
Should be fixed by 

2008-08-21  Matthias Clasen  <mclasen@redhat.com>

        * gtk/gtksettings.c: When reconstructing the color hash, try
        harder to avoid unnecessary notification, since this can lead
        to infinite reloading of rc files in some situations.
Comment 6 Richard Fuller 2008-10-21 15:31:55 UTC
I have upgraded to gtk 2.12.12, which contains the fix. However, the problem still occurs (infinite loop) when the user's colour settings in Gnome are different to the colours specified in the theme included from /etc/gtk-2.0/gtkrc

In this case each time update_color_hash is called the values in the old hash are different to the values in the new hash.

Inserting a statement to output the old and new colour values for debugging shows an oscillating infinite loop of output like:

Gtk-Message: *** (new value != value) [new_value = 62965,62965,46517, value = 65535,61937,48830]***

Gtk-Message: *** (new value != value) [new_value = 65535,61937,48830, value = 62965,62965,46517]***

Gtk-Message: *** (new value != value) [new_value = 62965,62965,46517, value = 65535,61937,48830]***

Gtk-Message: *** (new value != value) [new_value = 65535,61937,48830, value = 62965,62965,46517]***
Comment 7 Volodymyr Khomchak 2009-02-22 08:08:52 UTC
Jens, please Reopen this bug !
I still able to reproduce it in gnome version 2.22.3.


Comment 8 Matthias Clasen 2013-02-13 04:22:56 UTC
color schemes are gone in gtk3