GNOME Bugzilla – Bug 546834
Crash after GtkTreeView's validate_visible_area
Last modified: 2018-02-10 03:41:03 UTC
Version: 2.22.2 What were you doing when the application crashed? Trying to get today task list clicking over the clock Distribution: Fedora release 9 (Sulphur) Gnome Release: 2.22.3 2008-07-01 (Red Hat, Inc) BugBuddy Version: 2.22.0 System: Linux 2.6.25.11-97.fc9.x86_64 #1 SMP Mon Jul 21 01:09:10 EDT 2008 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10499905 Selinux: Enforcing Accessibility: Disabled GTK+ Theme: Mist Icon Theme: Mist Memory status: size: 445145088 vsize: 445145088 resident: 19251200 share: 11587584 rss: 19251200 rss_rlim: 18446744073709551615 CPU usage: start_time: 1218128285 rtime: 54 utime: 43 stime: 11 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/libexec/clock-applet' [Thread debugging using libthread_db enabled] [New Thread 0x7f2b283807f0 (LWP 4518)] [New Thread 0x40926950 (LWP 4522)] 0x0000003569a0e86f in __libc_waitpid (pid=<value optimized out>, stat_loc=<value optimized out>, options=<value optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:41 41 int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);
+ Trace 204812
----------- .xsession-errors (87 sec old) --------------------- CalDAV Eplugin starting up ... e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have key 'imap:__quintela@trasno.org_' e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have key 'zimbra:__quintela@localhost:2231_' e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have key 'imap:__quintela@localhost:2227_' (evolution:3921): e-data-server-ui-WARNING **: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results) e-data-server-ui-Message: Key file does not have key 'imap:__quintela@trasno.org_' (evolution:3921): gtkhtml-WARNING **: oo (evolution:3921): gtkhtml-WARNING **: oo --------------------------------------------------
*** Bug 551151 has been marked as a duplicate of this bug. ***
Looks like it might be a GTK+ bug, although the trace is a little odd.
Seems to be an interplay between GtkTreeView and the size group mechanism. Will try to get to this later.
*** Bug 559248 has been marked as a duplicate of this bug. ***
*** Bug 560651 has been marked as a duplicate of this bug. ***
Is this still reproducible and if so how? I went through all the hassle to get gnome-panel and deps correctly built (all from git master), but I cannot get the clock applet to crash.
Oh, as a sidenote. The crash does not occur *after* validate_visible_area(), but at the end of validate_visble_area(). At this point GtkTreeView will call gtk_widget_size_request() on itself (to be able to update the adjustments) and this triggers the size group logic.
I have a very similar trace when trying to add an entry in Collabora's gtimelog [1] using GTK+ 2.18.0-1ubuntu1 (Karmic). [1] http://git.collabora.co.uk/?p=gtimelog.git;a=summary
+ Trace 217799
Will attach the full trace.
Full trace:
+ Trace 217800
Valgrind log of the bug: ==3779== Invalid read of size 8 ==3779== at 0x90A2639: validate_visible_area (gtktreeview.c:5770) ==3779== by 0x90A2F01: do_presize_handler (gtktreeview.c:6300) ==3779== by 0x90A2F98: presize_handler_callback (gtktreeview.c:6322) ==3779== by 0x94967C5: gdk_threads_dispatch (gdk.c:506) ==3779== by 0x80FDBBD: g_main_context_dispatch (gmain.c:1960) ==3779== by 0x8101587: g_main_context_iterate (gmain.c:2591) ==3779== by 0x81019E4: g_main_loop_run (gmain.c:2799) ==3779== by 0x8FA7FC6: gtk_main (gtkmain.c:1205) ==3779== by 0x8B7CEC1: (within /usr/lib/pyshared/python2.6/gtk-2.0/gtk/_gtk.so) ==3779== by 0x4A291C: PyEval_EvalFrameEx (ceval.c:3690) ==3779== by 0x4A2E46: PyEval_EvalFrameEx (ceval.c:3792) ==3779== by 0x4A40DF: PyEval_EvalCodeEx (ceval.c:2968) ==3779== by 0x4A41B1: PyEval_EvalCode (ceval.c:522) ==3779== by 0x4C338F: PyRun_FileExFlags (pythonrun.c:1335) ==3779== by 0x4C3553: PyRun_SimpleFileExFlags (pythonrun.c:931) ==3779== by 0x418AB6: Py_Main (main.c:599) ==3779== by 0x5907ABC: (below main) (libc-start.c:220) ==3779== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==3779== ==3779== Process terminating with default action of signal 11 (SIGSEGV) ==3779== Access not within mapped region at address 0x10 ==3779== at 0x90A2639: validate_visible_area (gtktreeview.c:5770) ==3779== by 0x90A2F01: do_presize_handler (gtktreeview.c:6300) ==3779== by 0x90A2F98: presize_handler_callback (gtktreeview.c:6322) ==3779== by 0x94967C5: gdk_threads_dispatch (gdk.c:506) ==3779== by 0x80FDBBD: g_main_context_dispatch (gmain.c:1960) ==3779== by 0x8101587: g_main_context_iterate (gmain.c:2591) ==3779== by 0x81019E4: g_main_loop_run (gmain.c:2799) ==3779== by 0x8FA7FC6: gtk_main (gtkmain.c:1205) ==3779== by 0x8B7CEC1: (within /usr/lib/pyshared/python2.6/gtk-2.0/gtk/_gtk.so) ==3779== by 0x4A291C: PyEval_EvalFrameEx (ceval.c:3690) ==3779== by 0x4A2E46: PyEval_EvalFrameEx (ceval.c:3792) ==3779== by 0x4A40DF: PyEval_EvalCodeEx (ceval.c:2968) ==3779== by 0x4A41B1: PyEval_EvalCode (ceval.c:522) ==3779== by 0x4C338F: PyRun_FileExFlags (pythonrun.c:1335) ==3779== by 0x4C3553: PyRun_SimpleFileExFlags (pythonrun.c:931) ==3779== by 0x418AB6: Py_Main (main.c:599) ==3779== by 0x5907ABC: (below main) (libc-start.c:220)
Great traces! I think I am seeing the issue already. If I would prepare a small patch, could you quickly give that a try and see if it fixes the issue?
sure!
Okay, I reasoned a bit too quick. Two things: 1. The traces in comments 8 to 10 are not related to this bug. I suggest a new bug is opened for this. 2. When we open a new bug, could you please provide an exact sequence of steps that reproduces the issue. I am not seeing any legal way to get into that state (at gtktreeview.c line 5770 with tree and node NULL). A quick look at the gtimelog source showed that it does not do anything special with the tree view, not even sets cursors or scrolls, so I am really wondering how it can get in such a state. This is always reproducible?
I opened bug #596308
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.