GNOME Bugzilla – Bug 765165
Anting sometimes uses too much cpu
Last modified: 2018-05-22 14:24:50 UTC
Created attachment 326177 [details] stack traces from loop 100% cpu Recipe: Start a fresh copy of gnumeric. Click on the "A" column header, to select the whole column. (Select more than one column if you wish.) Type ^C to copy the region to the clipboard. Observe 100% CPU usage. Not good. I'm not sure whether this should be classified "General" or "Main" or "Gui" or whatever, so I took a wild guess. To obtain a possible hint about what's going on, I interrupted the loop using SIGUSR1. See attached file with stack traces. Possible workaround / recovery: Do whatever you want with the copied stuff, then select some single cell and type ^C. CPU usage drops immediately. Note: I rated it "minor" because this bug is *not* very important to me. That's because of the relatively simple and obvious workaround / recovery. ============ This bug has been around for ages, provably since 1.12.22 and almost certainly much longer than that. However this report is based on a freshly-pulled git version: gnumeric version '1.12.29' datadir := '/usr/local/share/gnumeric/1.12.29' libdir := '/usr/local/lib/gnumeric/1.12.29' commit 1a58d23634c58d58dec12300ed55f0d13d0e76b1 Date: Fri Apr 1 19:38:01 2016 -0400 uname -a Linux asclepias 3.18.0+ #4 SMP Mon Jul 6 15:51:42 MST 2015 x86_64 x86_64 x86_64 GNU/Linux lsb_release LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
I am unable to reproduce. The cpu load does not change significantly for me.
1) FWIW, this is 100% reproducible chez moi. 2) It is associated with a steady memory leak. See attached memleak.gnumeric The memory is not freed when the column is deselected, as indicated by the black vertical line in the graph.
Created attachment 326208 [details] graph of memory leak vesus time
I can't reproduce it. After several cycles, I'm just getting one possible leak from valgrind: ==21371== 640 bytes in 1 blocks are possibly lost in loss record 13,024 of 13,518 ==21371== at 0x4C2BDDF: realloc (vg_replace_malloc.c:785) ==21371== by 0x8ED7777: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0) ==21371== by 0x8C619D8: type_node_any_new_W (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0) ==21371== by 0x8C672CC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0) ==21371== by 0x8C4643D: g_enum_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0) ==21371== by 0x533C236: gnm_align_v_get_type (style.c:382) ==21371== by 0x53A670F: xml_write_style (xml-sax-write.c:493) ==21371== by 0x53A738D: xml_write_style_region (xml-sax-write.c:692) ==21371== by 0x53AAB0C: gnm_cellregion_to_xml (xml-sax-write.c:1645) ==21371== by 0x51F18DF: x_clipboard_get_cb (gui-clipboard.c:882) ==21371== by 0x8C44FA4: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0) ==21371== by 0x8C56FC0: signal_emit_unlocked_R (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4800.0) Can you provide a valgrind output?
You very likely have a buggy clipboard manager that keeps asking Gnumeric for the current selection in a dozen different formats, including several image formats. Try running with "GNM_DEBUG=clipboard" set. You should see only a few output lines.
1) The clipboard hypothesis is not supported by observations: 1a) I did the experiment as suggested: :; GNM_DEBUG=clipboard /usr/local/bin/gnumeric Gtk-Message: Failed to load module "canberra-gtk-module" Gtk-Message: Failed to load module "canberra-gtk-module" Clipboard successfully claimed. # observe 100% cpu ^C The canberra messages are very common on my machine. 1b) I switched window managers (compiz <--> metacity) and observed all the same symptoms. ============== 2) See attached valgrind.logg
Created attachment 326266 [details] valgrind report, as requested
We're going to need some kind of profile telling us what is going on. 1. Using the "top" program, verify that it is indeed Gnumeric that is using up 100% of the cpu. If more than one program is running hot, it might be because they are talking to each other. 2. Run under gdb and stop the program a few times to get stack traces and see if there is any pattern in what it is doing. gdb /path/to/gnumeric run # trigger that problem here Ctrl-C where cont # wait a few seconds Ctrl-C where cont ...
1) Gnumeric is eating 100% cpu all by itself. 2) As mentioned in the original bug report, a couple of weeks ago: >> To obtain a possible hint about what's going on, I interrupted >> the loop using SIGUSR1. See attached file with stack traces. See https://bug765165.bugzilla-attachments.gnome.org/attachment.cgi?id=326177 If that's not good enough, please explain in more detail what you want. Let me know if there is any other information I can provide.
Ah, didn't see that. Current suspect: the "ants" around the copied selection. Does the cpu usage drop if you press Esc?
>> Does the cpu usage drop if you press Esc? Yes. Esc stops the ants and stops the CPU hogging.
Good. At least we now understand what is causing it.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/302.