GNOME Bugzilla – Bug 612919
crash in System Monitor: I was moving up-down wit...
Last modified: 2010-08-10 04:34:51 UTC
Version: 2.28.0 What were you doing when the application crashed? I was moving up-down with page up and page down buttons in memory map view Distribution: Gentoo Base System release 2.0.1 Gnome Release: 2.28.2 2010-03-07 (Gentoo) BugBuddy Version: 2.28.0 System: Linux 2.6.33-04714-geaa5eec #190 SMP Thu Mar 4 11:57:24 EET 2010 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10705000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Compact Icon Theme: gnome GTK+ Modules: canberra-gtk-module, gnomebreakpad Memory status: size: 356732928 vsize: 356732928 resident: 25395200 share: 18915328 rss: 25395200 rss_rlim: 18446744073709551615 CPU usage: start_time: 1268637321 rtime: 3491 utime: 2408 stime: 1083 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/gnome-system-monitor' [Thread debugging using libthread_db enabled] Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.2304.0-gdb.py", line 9, in <module> from gobject import register File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module> import gdb.backtrace ImportError: No module named backtrace 0x00007ff616908b8e in __libc_waitpid (pid=<value optimized out>, stat_loc= 0x7fff1f8b24e0, options=<value optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:32 in ../sysdeps/unix/sysv/linux/waitpid.c Current language: auto The current source language is "auto; currently c".
+ Trace 220963
Thread 1 (Thread 0x7ff619af2780 (LWP 4997))
Inferior 1 [process 4997] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal]
-> gtk+
*** Bug 616299 has been marked as a duplicate of this bug. ***
Created attachment 166849 [details] [review] Fix unstable segfault error in treeview after pressing page down button This patch for gtk+-2.18.9
I have the same problem. In both cases (nautilus and system-monitor) tree view model has many periodical (by g_timeout and g_idle) changes (deleting and inserting row). Treeview queue size-request operation after change. By default this operation will perform only in idle mode. If we press “PageDown” button after row deletion treeview cursor position can go out of treevew height. The following block of code must pervent this situation (gtktreeview.c:9700 in gtk+-2.18.9): if (y >=tree_view->priv->heigth) y = tree_view->priv->heigth - 1; But tree_view->priv->height will be correct only after tree view processed size-request. If we press “PageDown” immediately after deletion, size-request doesn’t yet processed by treeview. If cursor offset become more then tree_view->priv->heigth - <height of deleted row> then function _gtk_rbtree_find_offset return cursor_tree and cursor_node as NULL. Accordingly macro BACKGROUND_HEIGHT (cursor_node) (gtktreeview.c:9707 in gtk+-2.18.9) raise segmentation fault error Attached patch include force call of gtk_container_check_resize if one of treeview’s parent has pending resize. Sorry for my English.
I don't think this fix is the best one. If you look in the cursor motion functions around there, we already have numerous instances of if (cursor_tree == NULL) { /* FIXME: we lost the cursor. Should we try to get one? */ gtk_tree_path_free (old_cursor_path); return; } We should probably just add one more after the find_offset call.
I agree with Matthias.
Could somebody test if the proposed fix from comment 5 will solve the problem? I don't have a stand-alone test case handy here ...
It fix segfault, but: 1. tree_view->priv->cursor_offset = _gtk_rbtree_find_offset (tree_view->priv->tree, y, &cursor_tree, &cursor_node); cursor_offset will become zero 2. "PageDown" click (when tree cursor near bottom and click happened after row deleting and before size-request exceucting) will ignore If isn't essential, then decision from comment 5 is better.