GNOME Bugzilla – Bug 160803
extremely high load (lots of IO?); can make system completely unresponsive
Last modified: 2005-02-23 17:19:06 UTC
I've had this happen several times now; I first noticed it with 2.6 code but it may be older than that. Basically, open g-t-m, play around a bit, watch system load rise constantly until system is completely unresponsive. Today was the first time in ages I've had to reboot because of application software, and it sucked. :/ I seem to get a lot of these when the problem is worst, but that may be coincidence: (gnome-theme-manager:6360): capplet-common-CRITICAL **: generate_theme_thumbnail: assertion `async_data.set == FALSE' failed Maddeningly, I can't duplicate (now that I'm set up to debug) the runaway loads I saw at least four times this morning. Grr. But even casual use (change theme, change theme details) causes a load of 2+ on my laptop that disappears as soon as I close g-t-m.
Created attachment 34646 [details] short bzip'ed strace I can repeatedly duplicate. happens 99% of the time for me. Attaching a short strace.
It would apear then when the manager is started if you are using one from the list it doesn't happen. However if you start with a custom theme, or subsequently modify the details, it happens quite reliably.
It would seem for some reason "window_settings_changed" is getting called ad infinitum when using a "custom" theme. Can't quite make out why yet, but that seems to be the source of trouble.
Created attachment 34657 [details] gdb backtraces Two GDB bt's, as per request. Don't think they will be much good, but here is hoping.
Created attachment 35138 [details] Stack traces of apps crashed while using theme-manager I played with the theme manager, switching gtk2 themes frantically (*clickclickclickclick*). The results: I got a gtk crash galore. I attach the stacktraces, compresesd for your leisure. BTW, trash-applet and epiphany were both visible and didn't crash. Xchat did but wouldn't produce an stack trace, bugbuddy-less as it is.
Sorry for forgetting this: using gnome HEAD on Debian Sid. The system usage of theme-manager was quite high, as described in this bug.
Also, when starting the theme-manager, the following themes were being thumbnailed: mist, crux, glider, grand canyon, big print, ocean dream, traditional. When I select for example "crux" (hard cause the list keeps scrolling up, as if thumbnailing fails and tries in an endless loop - easier if you use the down arrow in your keyboard), it gets rendered and thumbnailed after a short while, and all the themes too. Then CPU usage gets to stable levels.
I have been seeing the same cpu usage bug. After the patch in bug #149236 was applied the problem is better. I am now observing cpu usage between 2-3% as long as I have one of the prebuilt themes selected; however, when I click theme details and modify a theme and the selected theme becomes the "Custom theme", the cpu usage jumps to 100% and remains there.
I'll try to reproduce this while running under valgrind to see if there's any clue there.
I've seen the same crash myself that is reported in #5, but it only resulted in crashes in metacity while browsing through themes. The bug has been there for ages and it's about time we get this fixed. It looks like a bug in the smooth engine, but I couldn't find it myself. Finally some progress on these theme related issues...Marking with 2.10.0 milestone.
Please try the updated patch in bug #149236 to see if that helps with this problem too. I know there's still a crash in the smooth smooth engine, in addition to some leaks, but getting the crashes sorted out has to be the top priority. Traces from valgrind wrt the smooth engine problems: First a leak: ==28583== 3528 bytes in 55 blocks are definitely lost in loss record 145 of 170 ==28583== at 0x1B904BA9: calloc (vg_replace_malloc.c:175) ==28583== by 0x1C1EAA6B: IA__g_malloc0 (gmem.c:154) ==28583== by 0x1CC468D7: smooth_rc_style_init_data (smooth_gtk2_rc.c:79) ==28583== by 0x1CC46A51: smooth_rc_style_init (smooth_gtk2_rc.c:123) ==28583== by 0x1C1A440F: IA__g_type_create_instance (gtype.c:1596) ==28583== by 0x1C18F0C3: g_object_constructor (gobject.c:1045) ==28583== by 0x1C18E589: IA__g_object_newv (gobject.c:942) ==28583== by 0x1C18EFBF: IA__g_object_new_valist (gobject.c:985) ==28583== by 0x1C18F099: IA__g_object_new (gobject.c:823) ==28583== by 0x1BC3B480: gtk_rc_style_real_create_rc_style (gtkrc.c:1125) ==28583== by 0x1BC3C02E: gtk_rc_init_style (gtkrc.c:2111) ==28583== by 0x1BC3C55C: IA__gtk_rc_get_style (gtkrc.c:1713) ==28583== by 0x1BCDF3D8: gtk_widget_reset_rc_style (gtkwidget.c:4466) ==28583== by 0x1BCDF44E: reset_rc_styles_recurse (gtkwidget.c:4948) ==28583== by 0x1BC18885: gtk_menu_shell_forall (gtkmenushell.c:778) ==28583== by 0x1BB93C3C: IA__gtk_container_forall (gtkcontainer.c:1265) ==28583== by 0x1BCDF435: reset_rc_styles_recurse (gtkwidget.c:4951) ==28583== by 0x1BB5C388: gtk_bin_forall (gtkbin.c:166) ==28583== by 0x1BB93C3C: IA__gtk_container_forall (gtkcontainer.c:1265) ==28583== by 0x1BCDF435: reset_rc_styles_recurse (gtkwidget.c:4951) ==28583== by 0x1BB5C388: gtk_bin_forall (gtkbin.c:166) ==28583== by 0x1BB93C3C: IA__gtk_container_forall (gtkcontainer.c:1265) ==28583== by 0x1BCDF435: reset_rc_styles_recurse (gtkwidget.c:4951) ==28583== by 0x1BCDF492: IA__gtk_widget_reset_rc_styles (gtkwidget.c:4961) ==28583== by 0x1BC3B91D: gtk_rc_reset_widgets (gtkrc.c:1325) ==28583== by 0x1BBDE903: icon_size_settings_changed (gtkiconfactory.c:1066) ==28583== by 0x1C1A0658: IA__g_cclosure_marshal_VOID__PARAM (gmarshal.c:531) ==28583== by 0x1C18BD28: IA__g_closure_invoke (gclosure.c:437) ==28583== by 0x1C19E949: signal_emit_unlocked_R (gsignal.c:2485) ==28583== by 0x1C19F8CF: IA__g_signal_emit_valist (gsignal.c:2244) Then the crash: ==28586== Invalid read of size 1 ==28586== at 0x1B90553A: strcmp (mac_replace_strmem.c:249) ==28586== by 0x1C1B7E5D: IA__g_str_equal (gstring.c:69) ==28586== by 0x1C194C3E: IA__g_hash_table_lookup (ghash.c:203) ==28586== by 0x1C19084D: IA__g_quark_from_static_string (gdataset.c:592) ==28586== by 0x1CAEF1B6: smooth_rc_style_parse (smooth_gtk2_engine.c:76) ==28586== by 0x1BE1A639: gtk_rc_parse_style (gtkrc.c:3204) ==28586== by 0x1BE1AC85: gtk_rc_parse_any (gtkrc.c:2424) ==28586== by 0x1BE1B36B: gtk_rc_context_parse_one_file (gtkrc.c:827) ==28586== by 0x1BE1B451: gtk_rc_context_parse_file (gtkrc.c:893) ==28586== by 0x1BE1B635: gtk_rc_parse_named (gtkrc.c:644) ==28586== by 0x1BE1BA08: IA__gtk_rc_reparse_all_for_settings (gtkrc.c:1525) ==28586== by 0x1BE1BA68: gtk_rc_settings_changed (gtkrc.c:540) ==28586== by 0x1C161658: IA__g_cclosure_marshal_VOID__PARAM (gmarshal.c:531) ==28586== by 0x1C14CD28: IA__g_closure_invoke (gclosure.c:437) ==28586== by 0x1C15F949: signal_emit_unlocked_R (gsignal.c:2485) ==28586== by 0x1C1608CF: IA__g_signal_emit_valist (gsignal.c:2244) ==28586== by 0x1C160B1B: IA__g_signal_emit (gsignal.c:2288) ==28586== by 0x1C14E7BA: g_object_dispatch_properties_changed (gobject.c:593) ==28586== by 0x1C14DCC4: g_object_notify_dispatcher (gobject.c:234) ==28586== by 0x1C14EE0A: IA__g_object_notify (gobjectnotifyqueue.c:123) ==28586== by 0x1BE2744F: _gtk_settings_handle_event (gtksettings.c:1319) ==28586== by 0x1BDE6A24: IA__gtk_main_do_event (gtkmain.c:1232) ==28586== by 0x1C0A1499: gdk_event_dispatch (gdkevents-x11.c:2220) ==28586== by 0x1C1A0D70: IA__g_main_context_dispatch (gmain.c:1947) ==28586== by 0x1C1A264E: g_main_context_iterate (gmain.c:2578) ==28586== by 0x1C1A28CF: IA__g_main_loop_run (gmain.c:2782) ==28586== by 0x1BC5A07C: bonobo_main (bonobo-main.c:297) ==28586== by 0x1BC5876E: bonobo_generic_factory_main_timeout (bonobo-generic-factory.c:412) ==28586== by 0x1BC587DB: bonobo_generic_factory_main (bonobo-generic-factory.c:369) ==28586== by 0x1B90F8CA: panel_applet_factory_main_closure (panel-applet.c:1669) ==28586== Address 0x1C8C59E8 is not stack'd, malloc'd or (recently) free'd
Has anyone here tested with current CVS to see if that helps?
I avoided the smooth engine in order to avoid the crashes. I have gathered a couple profiles using oprofile. In case 1, I merely switch between non-custom themes (Bluecurve, Crux, Ocean Dream). In case 2, I go into the theme details and switch my gtk2 theme from Bluecurve to something else. As pointed out by Dennis, the first case uses very little cpu, and the latter basically pegs one of the CPUs and makes the other one pretty busy too. The profiles of just gnome-theme-manager are at http://www.gnome.org/~newren/temp/gnome-theme-manager.profile.1 http://www.gnome.org/~newren/temp/gnome-theme-manager.profile.2 The system wide profiles are at http://www.gnome.org/~newren/temp/gnome-theme-manager.full-profile.1 http://www.gnome.org/~newren/temp/gnome-theme-manager.full-profile.2 Hope that helps...
Sorry for the spam, but with this patch: Index: common/theme-thumbnail.c =================================================================== RCS file: /cvs/gnome/gnome-control-center/capplets/common/theme-thumbnail.c,v retrieving revision 1.2 diff -p -u -r1.2 theme-thumbnail.c --- common/theme-thumbnail.c 2 Jul 2003 11:12:35 -0000 1.2 +++ common/theme-thumbnail.c 1 Feb 2005 18:14:58 -0000 @@ -460,6 +460,9 @@ generate_theme_thumbnail (GnomeThemeMeta gint i, rowstride; char *pixels; + static int count = 0; + g_print ("Called this function for the %dth time.\n", ++count); + g_return_val_if_fail (async_data.set == FALSE, NULL); pixbuf = g_hash_table_lookup (theme_hash, meta_theme_info->name); it is apparent that generate_theme_thumbnail is called exactly twice per theme change when using a non-custom theme, and is incessantly called approximately 3.5 times per second otherwise.
It was suggested in the email thread on d-d-l about this bug that there was a race condition with gconf and set/gets, is there any way to see from your trace if that is causing the generate_theme_thumbnail, Elijah?
Appears to be--I'm trying to look closer.
I think the comment was from me "I've made a patch for a similar bug with the background capplet some time ago. The capplet is writting a gconf value in the callback function of the monitor on the same key (#153419). According to the capplet maintainer it works fine on his system and should not loop so he has not included the patch. BTW it fixes the issue we had with the package I've patched ... perhaps that's the same kind of problem here ?" if that can help ...
Here's the infinite loop: gnome-theme-manager.c:meta_theme_selection_changed -> gnome-theme-apply.c:gnome_meta_theme_set -> gnome-window-manager.c:gnome_window_manager_change_settings -> metacity-window-manager.c:change_settings -> <gconf calls to change the various settings> ... metacity-window-manager.c:value_changed -> gnome-window-manager.c:gnome_window_manager_settings_changed -> gnome-theme-manager.c:window_settings_changed -> gnome-theme-manager.c:update_settings_from_gconf -> <sets up idle handler> ... gnome-theme-manager.c:update_settings_from_gconf_idle -> gnome-theme-manager.c:add_custom_row_to_meta_theme -> gtk_tree_view_set_cursor [which emits selection_changed signal] ... gnome-theme-manager.c:meta_theme_selection_changed (ouch)
Created attachment 36850 [details] [review] One possible way to break the infinite loop This patch fixes the problem. There are probably other ways as well, given the length of the cycle, but this seemed the most obvious way to me.
Applied to both head and the gnome-2-8 branch (Kjartan approved it).
*** Bug 166305 has been marked as a duplicate of this bug. ***
Reopening : patch was not committed on gnome 2-8 branch (only changelog was) and missed 2.8.2 tarball release :(
I have no idea how I missed committing the real patch but got the changelog. Anyway, fixed now though you'll have to ping Kjartan or Sebastien or someone about whether they want to roll a new release.