Thanks for the bug report.  Unfortunately we need more info to know what's going on.

If you see gnome-main-menu using inordinate amounts of CPU, could you please do this:

  strace -ttt -f -p `pidof main-menu` -o /tmp/main-menu.strace

let it run for a few seconds, then kill the strace, and then attach /tmp/main-menu.strace to this bug report.

Thanks!

Created attachment 226200 [details]
main menu strace

It also leaks memory.  I'm not sure whether is strace it related.

*** Bug 406430 has been marked as a duplicate of this bug. ***

As a reference, can you please do the same strace after a restart.

Created attachment 226231 [details]
main menu strace after restart

I xkill'ed the panel and then called:

strace -ttt -f -p `pidof main-menu` -o /tmp/main-menu.strace

So - basically the straces don't look -that- interesting (sadly) ;-)

What I would recommend instead is manual stack trace polling ;-)

can you install the gnome-main-menu-debuginfo package, and when it starts to chew CPU attach with gdb, and do this:

while (looks slow) {
   ctrl-c
   thread apply all backtrace # (t a a bt)
   continue
   # human sleep random time ..
}

that should give us ~10 traces that will most likely show where the slowness is piling up.

Almost certainly it's a semantic leak of something that some slow algorithm is walking, that is never intended to grow big, but does somehow.

Thanks.

Too complicate for me.  Sigi seems also to be affected: https://bugzilla.novell.com/show_bug.cgi?id=406097

It's a rather serious issue.  I'd rather vote a GNOME hacker to reproduce it.

*** Bug 406097 has been marked as a duplicate of this bug. ***

Does this only happen on 32bit systems? What language are you using? If not English, would it be possible to see if it happens in English?

My locale is en_US.UTF-8.

I think all this is caused by incompatible settings done with a previous GNOME version.  I can also reproduce the behavior Sigi described when he did a new installation:

https://bugzilla.novell.com/show_bug.cgi?id=390683#c3 (bug 390683#c3 - wondering whether you tried to reproduce it?).

I can reproduce the same behavior on a 64bis system.

(During the night, the system crashed.  This time completely, not only the menu and Firefox.  I'm rather inclined to rate this as critical...).

So, in other words, you don't see this issue if you create and login as a new user?
I have a virtualized 10.3 machine. Will upgrade to 11.0 and see if I run into this issue.

sooo ... I leave my machine on for very long periods: I returned back from last night - having left it 8 hours or so, and immediately ssh'd from a remote machine (to avoid grab problems), attached gdb to main-menu, and clicked it.

I hit ctrl-c a few times as it was coming up [ around ~2 seconds of wall-clock time (outside the backtraces) ], and the breaks I managed to get both looked like:

(gdb) bt
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb6a2ed0f in __getdents (fd=22, buf=0x85b6018 "\221m\037", nbytes=<value optimized out>) at ../sysdeps/unix/sysv/linux/getdents.c:156
#2  0xb6a2e74d in __readdir (dirp=0x85b6000) at ../sysdeps/unix/readdir.c:66
#3  0xb7bbd423 in ?? () from /usr/lib/libgnomeui-2.so.0
#4  0xb7bbdc02 in ?? () from /usr/lib/libgnomeui-2.so.0
#5  0xb7bbed85 in gnome_thumbnail_factory_lookup () from /usr/lib/libgnomeui-2.so.0
#6  0xb7cee6c4 in document_tile_style_set (widget=0x8223818, prev_style=0x0) at document-tile.c:452
#7  0xb6bdd73c in IA__g_cclosure_marshal_VOID__OBJECT (closure=0x8096e38, return_value=0x0, n_param_values=2, param_values=0xbf995dd8, invocation_hint=0xbf995d14, marshal_data=0xb7cee580)
    at gmarshal.c:636
#8  0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096e38, return_value=0x0, n_param_values=2, param_values=0xbf995dd8, invocation_hint=0xbf995d14, marshal_data=0x90) at gclosure.c:567
#9  0xb6bd0beb in IA__g_closure_invoke (closure=0x8096e38, return_value=0x0, n_param_values=2, param_values=0xbf995dd8, invocation_hint=0xbf995d14) at gclosure.c:490
#10 0xb6be4880 in signal_emit_unlocked_R (node=0x808b558, detail=0, instance=0x8223818, emission_return=0x0, instance_and_params=0xbf995dd8) at gsignal.c:2370
#11 0xb6be64be in IA__g_signal_emit_valist (instance=0x8223818, signal_id=34, detail=0, var_args=0xbf995ff0 "\200") at gsignal.c:2199
#12 0xb6be6906 in IA__g_signal_emit (instance=0x8223818, signal_id=34, detail=0) at gsignal.c:2243
#13 0xb740604a in gtk_widget_set_style_internal (widget=0x8223818, style=0x8412558, initial_emission=1) at gtkwidget.c:6023
#14 0xb7406154 in gtk_widget_reset_rc_style (widget=0x8223818) at gtkwidget.c:5635
#15 0xb7343a87 in do_size_request (widget=0xff8) at gtksizegroup.c:618
#16 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x8223818, requisition=0xbf9960a4) at gtksizegroup.c:820
#17 0xb7405d6f in IA__gtk_widget_size_request (widget=0x8223818, requisition=0xbf9960a4) at gtkwidget.c:3635
#18 0xb71e4541 in gtk_alignment_size_request (widget=0x8224778, requisition=0x8224794) at gtkalignment.c:430
#19 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf996338, invocation_hint=0xbf996274, marshal_data=0xb71e44e0)
    at gmarshal.c:566
#20 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf996338, invocation_hint=0xbf996274, marshal_data=0x7c) at gclosure.c:567
#21 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf996338, invocation_hint=0xbf996274) at gclosure.c:490
#22 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x8224778, emission_return=0x0, instance_and_params=0xbf996338) at gsignal.c:2370
#23 0xb6be64be in IA__g_signal_emit_valist (instance=0x8224778, signal_id=29, detail=0, var_args=0xbf99658c "\n�OP�xG\"\b�e\231�g=4�xG\"\b4\002") at gsignal.c:2199
#24 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x8224778, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#25 0xb7343aa6 in do_size_request (widget=0x8224778) at gtksizegroup.c:620
#26 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x8224778, requisition=0x0) at gtksizegroup.c:820
#27 0xb7405d6f in IA__gtk_widget_size_request (widget=0x8224778, requisition=0x0) at gtkwidget.c:3635
#28 0xb735f967 in gtk_table_size_request (widget=0x8128148, requisition=0x8128164) at gtktable.c:960
#29 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9968d8, invocation_hint=0xbf996814, marshal_data=0xb735f830)
    at gmarshal.c:566
#30 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9968d8, invocation_hint=0xbf996814, marshal_data=0x7c) at gclosure.c:567
#31 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9968d8, invocation_hint=0xbf996814) at gclosure.c:490
#32 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x8128148, emission_return=0x0, instance_and_params=0xbf9968d8) at gsignal.c:2370
#33 0xb6be64be in IA__g_signal_emit_valist (instance=0x8128148, signal_id=29, detail=0, var_args=0xbf996b2c "Y����P�H\201\022\bXk\231�g=4�H\201\022\b4\002") at gsignal.c:2199
#34 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x8128148, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#35 0xb7343aa6 in do_size_request (widget=0x8128148) at gtksizegroup.c:620
#36 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x8128148, requisition=0xbf996b94) at gtksizegroup.c:820
#37 0xb7405d6f in IA__gtk_widget_size_request (widget=0x8128148, requisition=0xbf996b94) at gtkwidget.c:3635
#38 0xb71e4541 in gtk_alignment_size_request (widget=0x80d9238, requisition=0x80d9254) at gtkalignment.c:430
#39 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf996e28, invocation_hint=0xbf996d64, marshal_data=0xb71e44e0)
    at gmarshal.c:566
#40 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf996e28, invocation_hint=0xbf996d64, marshal_data=0x7c) at gclosure.c:567
#41 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf996e28, invocation_hint=0xbf996d64) at gclosure.c:490
#42 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x80d9238, emission_return=0x0, instance_and_params=0xbf996e28) at gsignal.c:2370
#43 0xb6be64be in IA__g_signal_emit_valist (instance=0x80d9238, signal_id=29, detail=0, var_args=0xbf99707c "�P��P�8\222\r\b�p\231�g=4�8\222\r\b4\002") at gsignal.c:2199
#44 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x80d9238, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#45 0xb7343aa6 in do_size_request (widget=0x80d9238) at gtksizegroup.c:620
#46 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x80d9238, requisition=0xbf9970e8) at gtksizegroup.c:820
#47 0xb7405d6f in IA__gtk_widget_size_request (widget=0x80d9238, requisition=0xbf9970e8) at gtkwidget.c:3635
#48 0xb73fae88 in gtk_vbox_size_request (widget=0x8101458, requisition=0x8101474) at gtkvbox.c:95
#49 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf997378, invocation_hint=0xbf9972b4, marshal_data=0xb73fae30)
    at gmarshal.c:566
#50 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf997378, invocation_hint=0xbf9972b4, marshal_data=0x7c) at gclosure.c:567
---Type <return> to continue, or q <return> to quit---
#51 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf997378, invocation_hint=0xbf9972b4) at gclosure.c:490
#52 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x8101458, emission_return=0x0, instance_and_params=0xbf997378) at gsignal.c:2370
#53 0xb6be64be in IA__g_signal_emit_valist (instance=0x8101458, signal_id=29, detail=0, var_args=0xbf9975cc "�P��P�X\024\020\b�\231�g=4�X\024\020\b4\002") at gsignal.c:2199
#54 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x8101458, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#55 0xb7343aa6 in do_size_request (widget=0x8101458) at gtksizegroup.c:620
#56 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x8101458, requisition=0xbf997638) at gtksizegroup.c:820
#57 0xb7405d6f in IA__gtk_widget_size_request (widget=0x8101458, requisition=0xbf997638) at gtkwidget.c:3635
#58 0xb73fae88 in gtk_vbox_size_request (widget=0x8101408, requisition=0x8101424) at gtkvbox.c:95
#59 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9978c8, invocation_hint=0xbf997804, marshal_data=0xb73fae30)
    at gmarshal.c:566
#60 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9978c8, invocation_hint=0xbf997804, marshal_data=0x7c) at gclosure.c:567
#61 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9978c8, invocation_hint=0xbf997804) at gclosure.c:490
#62 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x8101408, emission_return=0x0, instance_and_params=0xbf9978c8) at gsignal.c:2370
#63 0xb6be64be in IA__g_signal_emit_valist (instance=0x8101408, signal_id=29, detail=0, var_args=0xbf997b1c "Y����P�\b\024\020\bH{\231�g=4�\b\024\020\b4\002") at gsignal.c:2199
#64 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x8101408, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#65 0xb7343aa6 in do_size_request (widget=0x8101408) at gtksizegroup.c:620
#66 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x8101408, requisition=0xbf997b84) at gtksizegroup.c:820
#67 0xb7405d6f in IA__gtk_widget_size_request (widget=0x8101408, requisition=0xbf997b84) at gtkwidget.c:3635
#68 0xb71e4541 in gtk_alignment_size_request (widget=0x80d91d0, requisition=0x80d91ec) at gtkalignment.c:430
#69 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf997e18, invocation_hint=0xbf997d54, marshal_data=0xb71e44e0)
    at gmarshal.c:566
#70 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf997e18, invocation_hint=0xbf997d54, marshal_data=0x7c) at gclosure.c:567
#71 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf997e18, invocation_hint=0xbf997d54) at gclosure.c:490
#72 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x80d91d0, emission_return=0x0, instance_and_params=0xbf997e18) at gsignal.c:2370
#73 0xb6be64be in IA__g_signal_emit_valist (instance=0x80d91d0, signal_id=29, detail=0, var_args=0xbf99806c "�P��P��221\r\b\230\200\231�g=4��221\r\b4\002") at gsignal.c:2199
#74 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x80d91d0, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#75 0xb7343aa6 in do_size_request (widget=0x80d91d0) at gtksizegroup.c:620
#76 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x80d91d0, requisition=0xbf99813c) at gtksizegroup.c:820
#77 0xb7405d6f in IA__gtk_widget_size_request (widget=0x80d91d0, requisition=0xbf99813c) at gtkwidget.c:3635
#78 0xb72f4a06 in gtk_notebook_size_request (widget=0x8109800, requisition=0x810981c) at gtknotebook.c:1821
#79 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9983e8, invocation_hint=0xbf998324, marshal_data=0xb72f48f0)
    at gmarshal.c:566
#80 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9983e8, invocation_hint=0xbf998324, marshal_data=0x7c) at gclosure.c:567
#81 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9983e8, invocation_hint=0xbf998324) at gclosure.c:490
#82 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x8109800, emission_return=0x0, instance_and_params=0xbf9983e8) at gsignal.c:2370
#83 0xb6be64be in IA__g_signal_emit_valist (instance=0x8109800, signal_id=29, detail=0, var_args=0xbf99863c "�P��P�") at gsignal.c:2199
#84 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x8109800, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#85 0xb7343aa6 in do_size_request (widget=0x8109800) at gtksizegroup.c:620
#86 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x8109800, requisition=0xbf9986a8) at gtksizegroup.c:820
#87 0xb7405d6f in IA__gtk_widget_size_request (widget=0x8109800, requisition=0xbf9986a8) at gtkwidget.c:3635
#88 0xb73fae88 in gtk_vbox_size_request (widget=0x8085238, requisition=0x8085254) at gtkvbox.c:95
#89 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf998938, invocation_hint=0xbf998874, marshal_data=0xb73fae30)
    at gmarshal.c:566
#90 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf998938, invocation_hint=0xbf998874, marshal_data=0x7c) at gclosure.c:567
#91 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf998938, invocation_hint=0xbf998874) at gclosure.c:490
#92 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x8085238, emission_return=0x0, instance_and_params=0xbf998938) at gsignal.c:2370
#93 0xb6be64be in IA__g_signal_emit_valist (instance=0x8085238, signal_id=29, detail=0, var_args=0xbf998b8c "Y����P�8R\b\b�\213\231�g=4�8R\b\b4\002") at gsignal.c:2199
#94 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x8085238, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#95 0xb7343aa6 in do_size_request (widget=0x8085238) at gtksizegroup.c:620
#96 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x8085238, requisition=0xbf998bf4) at gtksizegroup.c:820
#97 0xb7405d6f in IA__gtk_widget_size_request (widget=0x8085238, requisition=0xbf998bf4) at gtkwidget.c:3635
#98 0xb71e4541 in gtk_alignment_size_request (widget=0x80d8620, requisition=0x80d863c) at gtkalignment.c:430
#99 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf998e88, invocation_hint=0xbf998dc4, marshal_data=0xb71e44e0)
    at gmarshal.c:566
#100 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf998e88, invocation_hint=0xbf998dc4, marshal_data=0x7c)
    at gclosure.c:567
---Type <return> to continue, or q <return> to quit---
#101 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf998e88, invocation_hint=0xbf998dc4) at gclosure.c:490
#102 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x80d8620, emission_return=0x0, instance_and_params=0xbf998e88) at gsignal.c:2370
#103 0xb6be64be in IA__g_signal_emit_valist (instance=0x80d8620, signal_id=29, detail=0, var_args=0xbf9990dc "\027���P� \206\r\b\b\221\231�g=4� \206\r\b4\002") at gsignal.c:2199
#104 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x80d8620, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#105 0xb7343aa6 in do_size_request (widget=0x80d8620) at gtksizegroup.c:620
#106 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x80d8620, requisition=0xbf999148) at gtksizegroup.c:820
#107 0xb7405d6f in IA__gtk_widget_size_request (widget=0x80d8620, requisition=0xbf999148) at gtkwidget.c:3635
#108 0xb728fe48 in gtk_hbox_size_request (widget=0x80851e8, requisition=0x8085204) at gtkhbox.c:97
#109 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9993d8, invocation_hint=0xbf999314, marshal_data=0xb728fdf0)
    at gmarshal.c:566
#110 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9993d8, invocation_hint=0xbf999314, marshal_data=0x7c)
    at gclosure.c:567
#111 0xb6bd0b18 in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf9993d8, invocation_hint=0xbf999314) at gclosure.c:490
#112 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x80851e8, emission_return=0x0, instance_and_params=0xbf9993d8) at gsignal.c:2370
#113 0xb6be64be in IA__g_signal_emit_valist (instance=0x80851e8, signal_id=29, detail=0, var_args=0xbf99962c "�;���P��\b\bX\226\231�g=4��\b\b4\002") at gsignal.c:2199
#114 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x80851e8, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#115 0xb7343aa6 in do_size_request (widget=0x80851e8) at gtksizegroup.c:620
#116 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x80851e8, requisition=0xbf99969c) at gtksizegroup.c:820
#117 0xb7405d6f in IA__gtk_widget_size_request (widget=0x80851e8, requisition=0xbf99969c) at gtkwidget.c:3635
#118 0xb740ea1a in gtk_window_size_request (widget=0x80e60d0, requisition=0x80e60ec) at gtkwindow.c:4707
#119 0xb6bdd89c in IA__g_cclosure_marshal_VOID__BOXED (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf999928, invocation_hint=0xbf999864, marshal_data=0xb740e9e0)
    at gmarshal.c:566
#120 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf999928, invocation_hint=0xbf999864, marshal_data=0x7c)
    at gclosure.c:567
#121 0xb6bd0beb in IA__g_closure_invoke (closure=0x8096db8, return_value=0x0, n_param_values=2, param_values=0xbf999928, invocation_hint=0xbf999864) at gclosure.c:490
#122 0xb6be4880 in signal_emit_unlocked_R (node=0x8067640, detail=0, instance=0x80e60d0, emission_return=0x0, instance_and_params=0xbf999928) at gsignal.c:2370
#123 0xb6be64be in IA__g_signal_emit_valist (instance=0x80e60d0, signal_id=29, detail=0, var_args=0xbf999b7c "") at gsignal.c:2199
#124 0xb6be67a5 in IA__g_signal_emit_by_name (instance=0x80e60d0, detailed_signal=0xb74c783a "size_request") at gsignal.c:2267
#125 0xb7343aa6 in do_size_request (widget=0x80e60d0) at gtksizegroup.c:620
#126 0xb7343d67 in _gtk_size_group_compute_requisition (widget=0x80e60d0, requisition=0x0) at gtksizegroup.c:820
#127 0xb7405d6f in IA__gtk_widget_size_request (widget=0x80e60d0, requisition=0x0) at gtkwidget.c:3635
#128 0xb740ee23 in gtk_window_compute_configure_request (window=0x80e60d0, request=0xbf999d38, geometry=0xbf999d04, flags=0xbf999d58) at gtkwindow.c:5563
#129 0xb7418cbd in gtk_window_show (widget=0x80e60d0) at gtkwindow.c:4258
#130 0xb6bde234 in IA__g_cclosure_marshal_VOID__VOID (closure=0x8096470, return_value=0x0, n_param_values=1, param_values=0xbf999fd8, invocation_hint=0xbf999f14, marshal_data=0xb7418c40)
    at gmarshal.c:77
#131 0xb6bcf339 in g_type_class_meta_marshal (closure=0x8096470, return_value=0x0, n_param_values=1, param_values=0xbf999fd8, invocation_hint=0xbf999f14, marshal_data=0x5c)
    at gclosure.c:567
#132 0xb6bd0beb in IA__g_closure_invoke (closure=0x8096470, return_value=0x0, n_param_values=1, param_values=0xbf999fd8, invocation_hint=0xbf999f14) at gclosure.c:490
#133 0xb6be4880 in signal_emit_unlocked_R (node=0x80964b8, detail=0, instance=0x80e60d0, emission_return=0x0, instance_and_params=0xbf999fd8) at gsignal.c:2370
#134 0xb6be64be in IA__g_signal_emit_valist (instance=0x80e60d0, signal_id=23, detail=0, var_args=0xbf99a1ec "�201@�\020P\016\bLj(\002(�\231��\004\b�\016\bLj(\002\001") at gsignal.c:2199
#135 0xb6be6906 in IA__g_signal_emit (instance=0x80e60d0, signal_id=23, detail=0) at gsignal.c:2243
#136 0xb740828c in IA__gtk_widget_show (widget=0x80e60d0) at gtkwidget.c:2943
#137 0x0804fbf0 in panel_button_clicked_cb (button=0x8104ad0, user_data=0x80e5000) at main-menu-ui.c:1860
#138 0xb6bde234 in IA__g_cclosure_marshal_VOID__VOID (closure=0x8114b80, return_value=0x0, n_param_values=1, param_values=0xbf99a468, invocation_hint=0xbf99a3a4, marshal_data=0x804faa0)
    at gmarshal.c:77
#139 0xb6bd0beb in IA__g_closure_invoke (closure=0x8114b80, return_value=0x0, n_param_values=1, param_values=0xbf99a468, invocation_hint=0xbf99a3a4) at gclosure.c:490
#140 0xb6be5007 in signal_emit_unlocked_R (node=0x8102968, detail=0, instance=0x8104ad0, emission_return=0x0, instance_and_params=0xbf99a468) at gsignal.c:2440
#141 0xb6be64be in IA__g_signal_emit_valist (instance=0x8104ad0, signal_id=171, detail=0, var_args=0xbf99a67c "\020P\016\b\020P\016\b �004\b��\231�\212�004\b�\020\b\001")
    at gsignal.c:2199
#142 0xb6be6906 in IA__g_signal_emit (instance=0x8104ad0, signal_id=171, detail=0) at gsignal.c:2243
#143 0xb71f5c8a in IA__gtk_button_clicked (button=0x8104ad0) at gtkbutton.c:889
#144 0x0804fa8a in panel_button_button_press_cb (widget=0x8104ad0, event=0x83fb8a8, user_data=0x80e5000) at main-menu-ui.c:1901
#145 0xb72d6e16 in _gtk_marshal_BOOLEAN__BOXED (closure=0x8114b00, return_value=0xbf99a838, n_param_values=2, param_values=0xbf99a8e8, invocation_hint=0xbf99a824, marshal_data=0x804fa20)
    at gtkmarshalers.c:84
#146 0xb6bd0beb in IA__g_closure_invoke (closure=0x8114b00, return_value=0xbf99a838, n_param_values=2, param_values=0xbf99a8e8, invocation_hint=0xbf99a824) at gclosure.c:490
#147 0xb6be5007 in signal_emit_unlocked_R (node=0x8097f40, detail=0, instance=0x8104ad0, emission_return=0xbf99aaa8, instance_and_params=0xbf99a8e8) at gsignal.c:2440
---Type <return> to continue, or q <return> to quit---
#148 0xb6be634c in IA__g_signal_emit_valist (instance=0x8104ad0, signal_id=44, detail=0, var_args=0xbf99ab00 "\030�\231���?\b�\020\b�K@��\020\b�034\t\b") at gsignal.c:2209
#149 0xb6be6906 in IA__g_signal_emit (instance=0x8104ad0, signal_id=44, detail=0) at gsignal.c:2243
#150 0xb73ffb8e in gtk_widget_event_internal (widget=0x8104ad0, event=0x83fb8a8) at gtkwidget.c:4678
#151 0xb72cfa7c in IA__gtk_propagate_event (widget=0x8104ad0, event=0x83fb8a8) at gtkmain.c:2337
#152 0xb72d0e67 in IA__gtk_main_do_event (event=0x83fb8a8) at gtkmain.c:1542
#153 0xb6ff1a9a in gdk_event_dispatch (source=0x8088060, callback=0, user_data=0x0) at gdkevents-x11.c:2352
#154 0xb6b42079 in IA__g_main_context_dispatch (context=0x80880a8) at gmain.c:2009
#155 0xb6b455fb in g_main_context_iterate (context=0x80880a8, block=1, dispatch=1, self=0x805d0f0) at gmain.c:2642
#156 0xb6b45aca in IA__g_main_loop_run (loop=0x80928e8) at gmain.c:2850
#157 0xb760d0a3 in bonobo_main () at bonobo-main.c:311
#158 0xb760b279 in bonobo_generic_factory_main_timeout (act_iid=0x8092760 ":0.0,OAFIID:GNOME_MainMenu_Factory", factory_cb=0xb7f4f0a0 <panel_applet_factory_callback>, user_data=0x8092750, 
    quit_timeout=2000) at bonobo-generic-factory.c:411
#159 0xb760b303 in bonobo_generic_factory_main (act_iid=0x8092760 ":0.0,OAFIID:GNOME_MainMenu_Factory", factory_cb=0xb7f4f0a0 <panel_applet_factory_callback>, user_data=0x8092750)
    at bonobo-generic-factory.c:368
#160 0xb7f4f93d in panel_applet_factory_main_closure (iid=0x8058d8b "OAFIID:GNOME_MainMenu_Factory", applet_type=134817400, closure=<value optimized out>) at panel-applet.c:1754
#161 0xb7f4fa2b in panel_applet_factory_main (iid=0x8058d8b "OAFIID:GNOME_MainMenu_Factory", applet_type=134817400, callback=0x804e730 <main_menu_applet_init>, data=0x0)
    at panel-applet.c:1778
#162 0x0804e703 in main (argc=2059665, argv=0x0) at main-menu.c:36

Apparently the sizing logic does a load of I/O in the thumbnails directory - presumably this is doing something stupid for a non-visible pane in the menu.

Some more questions for the filers:

a) can you run $ time ls -lR ~/.thumbnails | wc -l # and paste the output
   NB. the first-time time is important - ie. when the system is fairly 'cold' or has been busy doing other things for a while. I have ~12k thumbnails myself which seems rather large and inefficient ;-)

b) can you confirm that when the slab is not popping up for all that time, the hard-disk light is on ?

c) can you move ~/.thumnails somewhere else [ don't worry it's a cache ], log out, log in again, and see if the problem persists ?

Thanks - [ hopefully we're nearer now ].

Michael,

Since you can reproduce... Another interesting bit to see what's going on could be to;

touch ~/main-menu-checkpoint.conf

Then restart g-m-m. This will create a 'main-menu-yyyy-mm-dd-hh-mm-ss.checkpoint' file in your home directory. If this is thumbnail related, we should see plenty of;

document-tile.c: load_image(): start for xyz

And it would contain the time of the call.

JFYI: 
I created a new local user on my machine yesterday and it running for about 21 h.
The startmenu behavior is normal in contrast to my normal network login.

> time ls -lR ~/.thumbnails | wc -l # 
7299

real    0m6.318s
user    0m0.124s
sys     0m0.500s

> time ls -lR ~/.thumbnails | wc -l #
7299

real    0m6.861s
user    0m0.104s
sys     0m0.384s

> time ls -lR ~/.thumbnails | wc -l #
7299

real    0m3.859s
user    0m0.100s
sys     0m0.356s

> time ls -lR ~/.thumbnails | wc -l #
7299

real    0m0.247s
user    0m0.100s
sys     0m0.144s

> time ls -lR ~/.thumbnails | wc -l #
7299

real    0m4.168s
user    0m0.092s
sys     0m0.420s

==============================================================

Probably not that helpful.... More tests tomorrow.  Just to calm down myself, I installed 10.3 from scratch plus all updates, did some Gnome desktop configurations, updated to 11.0 plus updates and cannot reproduce the main-menu issues on that installation.

We reinstalled OpenSUSE 11, performed updates, and allowed 5 users to start testing. Within a few hours, the machine came to a halt. So its not having something to do with OpenSuSE 11 betas, upgrading from 10.3, etc (this was our original configuration)

It looks to be a serious bug in opensuse and/or gnome -- we'll have to delay deployment until this is fixed.

found a few more details, I'm finding the same thing that Sieg did in Comment #14 -- it looks like if you recreate the user's home directory, the main menu stops acting up. 

I could notice an instant change from a network user. Once a network user logs in, the main-menu gets pegged around 2% cpu / 4% mem. If a localuser logs in with a new OpenSUSE 11 profile, the cpu is .1/.0 cpu and 1.5% mem. Haven't been logged in for more than 20 minutes, but there is definitely a difference upon login.

It'd be really annoying if all users have to recreate their home directories. Since we only have 25 users, its not that big of a deal, but I could see bigger user bases having a hard time with this.

Jakob, I'd like to confirm your observation.  I copied all my account data to a local account and logged in locally; there main-menu behaves fine.  But if I use my NIS account, main-menu eats memory and burns CPU cycles.

Ok, that should make it easier to reproduce it, thanks for digging into this guys.

Karl,

I'm using the Novell client + LUM to authenticate users on the OpenSUSE 11 box. Before, I had an NFS mount for /home, which contained all of our homedirs for users on SLED10. When we upgraded to OpenSUSE 11, all users experienced problems with main-menu eating up cycles.

The fix I did yesterday was to simply remove the nfs share, and allow Novell users to login, which recreated a new profile in OpenSUSE 11. I then made a symlink to their old profile by mounting the old homedir in /oldhome and adding the symlink to the startup scripts for each user. 

This is particularly annoying for those who use apps that are tied to gConf, since I had to go in an manually rip out code from the old profile and insert it into the new profile (specifically Evolution). Other apps were also set back to default settings. However, every one of our 25 novell LUM users are no logged into our OpenSUSE 11 box with new profiles and have no problems with main-menu.

Jakob, is your main-menu process constantly using CPU time, even if you are not using the menu?

Since you are using NFS, could you use a packet sniffer like wireshark to see if there is a lot of NFS activity from a machine that is otherwise idle?  Make sure that you test this while no "interesting" programs are running; I'd just like to know if main-menu is doing constant access to the file system or something like that.

As a test, can you please do this:

1. Start your desktop and wait a bit

2. Does main-menu take up a lot of CPU?

3. mv .thumbnails .thumbnails-old

4. killall main-menu

5. When the panel asks you if you want to restart the applet, say yes.

6. Does main-menu take up a lot of CPU now?

7. rm -rf .thumbnails; mv .thumbnails-old .thumbnails

Or does the CPU hogging only start happening after main-menu has been running for many hours?

Can people who see this issue please try my suggestion in https://bugzilla.novell.com/show_bug.cgi?id=406430#c11

OK, I'm finally convinced that gnome-main-menu is not the right place to be generating thumbnails.  I've committed the attached patch to SVN trunk; it removes the code to generate thumbnails.  We'll just let Nautilus handle that, as it already has the threading logic to generate thumbs in the background.

I'll submit this patch for openSUSE 11.0 as well.

Created attachment 230317 [details]
gnome-main-menu-bnc402256-no-thumbnails.diff

*** Bug 406430 has been marked as a duplicate of this bug. ***

Frederico, we noticed that after three weeks of running OpenSUSE 11, our users are starting to see main menu CPU issues again. I think you're right regarding NFS shares. We have two machines as follows
wksserv02: /home mounted ext3
wksserv01: wksserv02:/home mounted nfs

wksserv02 has no issues with main menu, while most users on wksserv01 have the main menu up near the top of the CPU load list.

The thumbnail fix (comment 23) you suggested fixed the problem for a little bit. But I haven't done the patch in comment 27 yet. I'll try to do that tonight when everyone leaves.

Created attachment 232385 [details]
Blank thumbnails on menu screenshot

if others are having trouble with this patch, I noticed one thing: some users when logging in will see the attached screenshot. It looks like their thumbnails are all screwed up.

It looks like all you need to do is logout and log back in, and it fixes itself.

Anja, could we please have a SWAMPID for this, for openSUSE 11.0?

This didn't make it with the bugs referenced in #412722, so I'd like to release it individually.

Thanks!

Thanks, submitted for openSUSE 11.0.

Jakob:  I don't think this patch is the cause for that bug... it doesn't deal with program icons at all; just with thumbnails for the user's data files.

released

(In reply to comment #33 from Federico Mena Quintero)
> Thanks, submitted for openSUSE 11.0.
> 
> Jakob:  I don't think this patch is the cause for that bug... it doesn't deal
> with program icons at all; just with thumbnails for the user's data files.

Yes, or no.  The symptom does still occur:


top - 17:02:48 up 7 days,  7:28, 14 users,  load average: 17.60, 13.12, 7.36
Tasks: 168 total,   2 running, 165 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.1%us, 41.7%sy,  0.0%ni,  0.0%id, 57.7%wa,  0.2%hi,  0.3%si,  0.0%st
Mem:   3085060k total,  3067764k used,    17296k free,      220k buffers
Swap:  1052248k total,  1052248k used,        0k free,    22708k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
   20 root      15  -5     0    0    0 D    8  0.0   1:28.13 kswapd0
 3784 ke        20   0  343m 8000  344 D    7  0.3   6:30.66 gweather-applet
27718 ke        20   0  843m 250m  264 D    6  8.3  64:10.86 firefox
 2216 root      20   0  271m  27m  476 D    6  0.9  38:05.05 X
11760 ke        20   0 3204m 2.3g  300 D    6 79.3   8:25.75 main-menu
...

During the weekend the main-menu already crashed once, and then, withing 8 hours a second time.

OK, your main-menu is using ridiculous amounts of memory.  We need to find out why it leaks.

Please do this:

1. killall main-menu

2. You'll get a dialog from gnome-panel asking you if you want to reload the main-menu,  *don't do anything in that dialog*.

3. In a terminal, run

  valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=300 --log-file=/tmp/main-menu.valgrind /usr/lib/gnome-main-menu/main-menu

   and leave the terminal running

4. Hit "reload" in gnome-panel's dialog from (2)

5. Let main-menu run for a while

6. Hit Control-C to kill the process, and wait for valgrind/main-menu to terminate (it takes a while)

7. Please attach /tmp/main-menu.valgrind to this bug.

I have the same problem with the main menu and tried it.
It seems that there is no "valgrind" on my machine. Which package do I need?

Ignore #37, I found it. Sorry.

sigi@d111:~> valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=300 --log-file=/tmp/main-menu.valgrind /usr/lib/gnome-main-menu/main-menu

** (slab:8646): WARNING **: 
error raised: [libslab_get_gconf_value: error getting /desktop/gnome/applications/main-menu/file-area/user_specified_apps]


** (slab:8646): WARNING **: nm_object_get_property: Error getting 'WirelessHardwareEnabled' for /org/freedesktop/NetworkManager: The name org.freedesktop.NetworkManager was not provided by any .service files


** (slab:8646): WARNING **: nm_client_new failed
^C

+++++++++++++++
main-menu.valgrind is in the next attachment

Created attachment 247701 [details]
main-menu.valgrind provided by sigi

openSUSE11 with all updates in SUSE developer network

Created attachment 248215 [details]
glib2-bnc402256-filename-leak.diff

This plugs a leak in GIO; we should add this to our glib2 package.  I've already committed it to GNOME SVN.

This is not the complete fix for main-menu's memory leaks; I'll follow up with some more patches...

Created attachment 248228 [details]
gnome-main-menu-leaks.diff

I committed this to SVN, but it needs to be put in our package.

Valgrind still reports that we leak the GtkTooltips objects (one per tile in the recent-documents tab), but I haven't found the reason :(

Submitted glib2 for openSUSE 11.1:

* Thu Nov 06 2008 - federico@novell.com
- Added glib2-bnc402256-filename-leak.diff as part of the fix for
  https://bugzilla.novell.com/show_bug.cgi?id=402256 - memory leaks
  found from gnome-main-menu.

Created attachment 250505 [details]
gnome-main-menu-bnc402256-leaks.diff

Found the main culprit!  We were leaking a bunch of strings and a big GtkTooltips object for each document tile.  I've already committed this patch upstream; will submit it for openSUSE 11.1 in a second.

Submitted gnome-main-menu for openSUSE 11.1.  This should fix the bug.  Karl, can you please test and reopen the bug if the problem still happens there?

* Thu Nov 06 2008 - federico@novell.com
- Added gnome-main-menu-bnc402256-leaks.diff to fix
  https://bugzilla.novell.com/show_bug.cgi?id=402256 - memory leaks
  while refreshing the list of recent documents.

Reopening the bug to submit the patches for openSUSE 11.0 as well.

Anja, I'd like to release these fixes for memory leaks in gnome-main-menu for openSUSE 11.0.  Could I please have a swampid?  Thanks!

update approved, 20879

Thanks; submitted a patchinfo for gnome-main-menu and glib2.

My 64-bit machine has this problem for a long time. I've reported this problem to Gnome developer group but no progress so far (http://bugzilla.gnome.org/show_bug.cgi?id=547334). 


I tried this new fix and it seems it doesn't work for my case ( after a few minutes I started gnome_main_menu I noticed the %MEM went from %6 to 7%). 


If you need any information please let me know.

sorry. in comment #51, %MEM from 0.6% to 0.7%.