GNOME Bugzilla – Bug 162764
nautilus crashes when choosing the "File group"
Last modified: 2006-08-21 09:44:28 UTC
Nautilus crashes when scrolling the "File group" in the Properties dialog with the mouse wheel. Steps to reproduce: 1. Open the Properties dialog for any file/directory 2. Use the mouse wheel to scroll trough the list of the option menu. If it doesn't crash, scroll faster. 3. If you scroll fast enough nautilus will crash.
Created attachment 35373 [details] gdb backtrace of nautilus
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Please make sure that the package was compiled with debugging symbols and see http://bugzilla.gnome.org/getting-traces.cgi for more information about useful stack traces. I don't get this crash here, what version of nautilus are you using ?
*** Bug 303758 has been marked as a duplicate of this bug. ***
I get the crash too when changing scrolling direction quickly Backtrace was generated from '/usr/bin/nautilus' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1224230528 (LWP 10533)] [New Thread -1240138832 (LWP 10573)] [New Thread -1239458896 (LWP 10557)] [New Thread -1239192656 (LWP 10556)] [New Thread -1238926416 (LWP 10555)] [New Thread -1238660176 (LWP 10554)] [New Thread -1238393936 (LWP 10553)] [New Thread -1238127696 (LWP 10552)] [New Thread -1228010576 (LWP 10542)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 59475
Thread 9 (Thread -1228010576 (LWP 10542))
Created attachment 46320 [details] Another backtrace
with debug eel Backtrace was generated from '/usr/bin/nautilus' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1224230528 (LWP 15083)] [New Thread -1239458896 (LWP 15090)] [New Thread -1239192656 (LWP 15089)] [New Thread -1238926416 (LWP 15088)] [New Thread -1238660176 (LWP 15087)] [New Thread -1238393936 (LWP 15086)] [New Thread -1238127696 (LWP 15085)] [New Thread -1228010576 (LWP 15084)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 59477
Thread 8 (Thread -1228010576 (LWP 15084))
I can easily reproduce this crash with gnome 2.10.2 too. Here is my log : (nautilus:2435): Gtk-CRITICAL **: gtk_tree_model_sort_get_value: assertion `GTK_TREE_MODEL_SORT (tree_model)->stamp == iter->stamp' failed (nautilus:2435): GLib-GObject-CRITICAL **: g_object_set_property: assertion `G_IS_VALUE (value)' failed (nautilus:2435): GLib-GObject-CRITICAL **: g_value_unset: assertion `G_IS_VALUE (value)' failed (nautilus:2435): Gtk-CRITICAL **: gtk_tree_model_sort_iter_next: assertion `GTK_TREE_MODEL_SORT (tree_model)->stamp == iter->stamp' failed (nautilus:2435): Gtk-CRITICAL **: file gtktreeview.c: line 3871 (gtk_tree_view_bin_expose): assertion `has_next' failed. There is a disparity between the internal view of the GtkTreeView, and the GtkTreeModel. This generally means that the model has changed without letting the view know. Any display from now on is likely to be incorrect. Eel-ERROR **: file eel-stock-dialogs.c: line 291 (eel_timed_wait_start_with_duration): assertion failed: (g_hash_table_lookup (timed_wait_hash_table, wait) == NULL) aborting... warning: The current VSYSCALL page code requires an existing execuitable. Use "add-symbol-file-from-memory" to load the VSYSCALL page by hand
This bug should be easiest to reproduce on network shares. The problem is that a second operation is started before the first one has finished. So I guess that the first operation needs to be canceled somehow.
Yes, Benjamin is right. We need an eel_timed_wait_pending API for cancelling old timed waits without issuing a g_return_if_fail statement when no old timed wait is pending. This bug isn't too prominent, so I think it can wait until 2.16.
Has any progress been made on this? I see that you said you were planning on waiting until 2.16. Well we're getting close...
The attached patch now uses a different approach: It delays the chown/chgrp some time to allow the window system to process some events (to allow smooth keyboard/scroll selection), saves whether a timed wait is actually running, and also makes the timed wait FMPropertiesWindow-specific. It used to be file-specific, which could have caused issues with multiple property windows which could register a timeout for the same file. Updating version/component.
The attached patch has some issues (see the list), but i've commited a working version.