GNOME Bugzilla – Bug 353127
Crash in _gtk_file_system_model_path_do
Last modified: 2007-09-07 08:06:17 UTC
Version: 2.15.8 What were you doing when the application crashed? i write script... Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.15.92 2006-08-22 (Ubuntu) BugBuddy Version: 2.15.92 Memory status: size: 76910592 vsize: 0 resident: 76910592 share: 0 rss: 24227840 rss_rlim: 0 CPU usage: start_time: 1156704221 rtime: 0 utime: 370 stime: 0 cutime:335 cstime: 0 timeout: 35 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1227000144 (LWP 5493)] (no debugging symbols found) 0xffffe410 in __kernel_vsyscall ()
+ Trace 71079
Thread 1 (Thread -1227000144 (LWP 5493))
It looks like a crash in the file chooser.
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
*** Bug 357687 has been marked as a duplicate of this bug. ***
*** Bug 360892 has been marked as a duplicate of this bug. ***
can anybody here still reproduce this issue when running the latest gtk+-2.10.5?
*** Bug 362030 has been marked as a duplicate of this bug. ***
*** Bug 363076 has been marked as a duplicate of this bug. ***
*** Bug 364256 has been marked as a duplicate of this bug. ***
*** Bug 364645 has been marked as a duplicate of this bug. ***
Can somebody of the bug reporters please install debug packages of gtk, glib and gnome-vfs and try to reproduce this crash, in order to help fixing this? Please see http://live.gnome.org/GettingTraces for more information. Thanks in advance.
*** Bug 365118 has been marked as a duplicate of this bug. ***
*** Bug 367371 has been marked as a duplicate of this bug. ***
Unfortunately, all the reported stack traces are missing some elements that will help a lot to solve the problem, so it will be hard for the developers to fix that crash. As Andre already asked in comment #10: cCan somebody of the bug reporters please install debug packages of gtk, glib and gnome-vfs and try to reproduce this crash, in order to help fixing this? Please see http://live.gnome.org/GettingTraces for more information. Thanks in advance.
*** Bug 371393 has been marked as a duplicate of this bug. ***
*** Bug 374057 has been marked as a duplicate of this bug. ***
*** Bug 372430 has been marked as a duplicate of this bug. ***
*** Bug 376413 has been marked as a duplicate of this bug. ***
*** Bug 376629 has been marked as a duplicate of this bug. ***
*** Bug 376986 has been marked as a duplicate of this bug. ***
*** Bug 377434 has been marked as a duplicate of this bug. ***
*** Bug 377704 has been marked as a duplicate of this bug. ***
*** Bug 377662 has been marked as a duplicate of this bug. ***
removing NEEDINFO: even if the stack traces are incomplete, they point out the location of the problem: void _gtk_file_system_model_path_do (GtkFileSystemModel *model, const GtkFilePath *path, GtkFileSystemModelPathFunc func, gpointer user_data) { ... if (gtk_file_path_compare (path, model->root_path) == 0 || !gtk_file_system_get_parent (model->file_system, path, &parent_path, NULL)) return; ... gtk_file_path_compare is just a strcmp so it crashes if one of the strings is NULL. Not sure if the one NULL is path or model->root_path, but the first sounds more likely. the if should become if (path && gtk_file_path_compare...) just for robustness. If calling the function with a NULL path is illegal, we should add a g_return_if_fail (path != NULL) and audit the callers.
*** Bug 379199 has been marked as a duplicate of this bug. ***
*** Bug 381868 has been marked as a duplicate of this bug. ***
*** Bug 383374 has been marked as a duplicate of this bug. ***
*** Bug 383650 has been marked as a duplicate of this bug. ***
*** Bug 384108 has been marked as a duplicate of this bug. ***
Ok, I tracked this down a bit more carefully: 1) To reproduce open a Save As dialog, open the expander, click on "Create Folder" and without entering the name click on one of the parent dirs in the path bar. The crash is actually happening in while (gtk_file_path_compare (parent_path, model->root_path) != 0) { ... since parent path can be NULL. It can be NULL because is obtained with gtk_file_system_get_parent(), which can return TRUE even if the parent is set to NULL. Quoting from its docs: * Return value: %TRUE if the operation was successful: @parent will be set to * the name of the @path's parent, or to %NULL if @path is already a file system * root. So to sum it up, a NULL parent_path needs to be handled in the loop (not sure if it should simply quit the loop or if something else is needed). I also still think that adding g_return_if_fail (GTK_IS_FILE_SYSTEM_MODEL (model)); g_return_if_fail (path != NULL); at the start of the function is a good idea to make sure that passing a null path to this function is illegal.
I just managed to reproduce the crash with my 2-10 branch. What happens is that the path to select is "file:///data/source/gnome/gtk%2B-2-10/tests" while the model root path is "file:///data/source/gnome/gtk%2B-2-10/Type%20name%20of%20new%20folder". Obviously there is no parent path which will ever reach the root path. I agree that adding the g_return_if_fail()s will help here, it won't fix the actual problem, but at least it will stop the segfaults. The actual problem is the following: * You click on Create Folder and don't touch the entry. * You click on a parent directory in the path bar. * The tree view loses focus, making it create the folder. * Because the click on the parent directory actually started a folder change, the folder is created in the wrong directory; the file chooser also enters this folder after creating it (hence the model root path above). * The pending path selections thinks the model root path is /data/source/gnome/gtk+-2-10 and wants to select "tests" there. The patch in #164494 is in HEAD now and with that I can't reproduce this anymore. Maybe we should also get this in 2-10, in addition to the g_return_if_fail()s.
*** Bug 385702 has been marked as a duplicate of this bug. ***
*** Bug 386576 has been marked as a duplicate of this bug. ***
*** Bug 388134 has been marked as a duplicate of this bug. ***
*** Bug 388705 has been marked as a duplicate of this bug. ***
*** Bug 388993 has been marked as a duplicate of this bug. ***
*** Bug 390253 has been marked as a duplicate of this bug. ***
Kristian, do you want to commit the patch from bug 164494 for 2-10, too ?
*** Bug 390926 has been marked as a duplicate of this bug. ***
*** Bug 391107 has been marked as a duplicate of this bug. ***
(In reply to comment #37) > Kristian, do you want to commit the patch from bug 164494 > for 2-10, too ? I hesitated directly committing this change for gtk-2-10 because it is in a fact a behavioural change. Of course I fully agree that people expect the change to be ignored if you move the mouse out of the window. (The text renderer did actually not stop editing on focus-out until a few years ago; from what I remember people were actually complaining that the change was not saved on focus-out). As far as people didn't do that already they now need to press either enter or one of the arrow keys, or click somewhere else in the same tree view to get the change accepted. Matthias, if that is fine with you I would be glad to commit this on 2-10 today/tomorrow.
I'm not sure we really want to cancel editing on focus-out. People complain about that, e.g. in bug 326892 and bug 317387. As long as the crash is fixed, I think we don't need further changes in 2.10. This is one of the cases where it might be nice to intercept the focus-out and ask for confirmation.
(In reply to comment #41) > I'm not sure we really want to cancel editing on focus-out. > People complain about that, e.g. in bug 326892 and bug 317387. > As long as the crash is fixed, I think we don't need further > changes in 2.10. Those bugs are really about problems in the combo cell renderer. > This is one of the cases where it might be nice to intercept the > focus-out and ask for confirmation. As argued in bug 164494 input should only be accepted after a user explicitly asked for that by pressing Enter or up/down arrows. I don't think asking for confirmation is nice for every case; it is probably not a thing gtk+ itself should handle. (Maybe it would be nice to support this in the GtkCellEditable framework at some point, I think I want to introduce a bunch of changes to it in 3.0 anyway). I will be committing the patch for 164494 to gtk-2-10 late tomorrow unless somebody objects.
Backmerged #164494 to gtk-2-10.
*** Bug 392350 has been marked as a duplicate of this bug. ***
Kris, should this be closed then ?
I'd appreciate some verifications that this is gone first. I remember having huge troubles reproducing this bug in the past ...
*** Bug 386929 has been marked as a duplicate of this bug. ***
*** Bug 385946 has been marked as a duplicate of this bug. ***
*** Bug 393894 has been marked as a duplicate of this bug. ***
*** Bug 395723 has been marked as a duplicate of this bug. ***
*** Bug 396303 has been marked as a duplicate of this bug. ***
*** Bug 397166 has been marked as a duplicate of this bug. ***
*** Bug 398816 has been marked as a duplicate of this bug. ***
*** Bug 399002 has been marked as a duplicate of this bug. ***
*** Bug 399562 has been marked as a duplicate of this bug. ***
*** Bug 400197 has been marked as a duplicate of this bug. ***
*** Bug 400410 has been marked as a duplicate of this bug. ***
*** Bug 401652 has been marked as a duplicate of this bug. ***
*** Bug 402142 has been marked as a duplicate of this bug. ***
Note to bugsquad: it would be very helpful to note if any of the recent dupes are with gtk+ 2.10.8 or newer
*** Bug 404712 has been marked as a duplicate of this bug. ***
*** Bug 404823 has been marked as a duplicate of this bug. ***
*** Bug 406152 has been marked as a duplicate of this bug. ***
*** Bug 407271 has been marked as a duplicate of this bug. ***
*** Bug 407717 has been marked as a duplicate of this bug. ***
*** Bug 369996 has been marked as a duplicate of this bug. ***
*** Bug 366815 has been marked as a duplicate of this bug. ***
*** Bug 397754 has been marked as a duplicate of this bug. ***
*** Bug 408486 has been marked as a duplicate of this bug. ***
*** Bug 408426 has been marked as a duplicate of this bug. ***
*** Bug 408743 has been marked as a duplicate of this bug. ***
*** Bug 410496 has been marked as a duplicate of this bug. ***
*** Bug 411023 has been marked as a duplicate of this bug. ***
*** Bug 412328 has been marked as a duplicate of this bug. ***
*** Bug 412431 has been marked as a duplicate of this bug. ***
*** Bug 412497 has been marked as a duplicate of this bug. ***
*** Bug 415433 has been marked as a duplicate of this bug. ***
*** Bug 401952 has been marked as a duplicate of this bug. ***
*** Bug 415510 has been marked as a duplicate of this bug. ***
*** Bug 415926 has been marked as a duplicate of this bug. ***
Putting this in NEEDINFO for now. Please reopen if you see a confirmed duplicate with GTK+ 2.10.8 or newer
*** Bug 417634 has been marked as a duplicate of this bug. ***
*** Bug 417831 has been marked as a duplicate of this bug. ***
*** Bug 418809 has been marked as a duplicate of this bug. ***
Ubuntu bug with GTK 2.10.11 and a similar backtrace: https://launchpad.net/bugs/93240
+ Trace 119816
Thread 1 (process 14774)
No symbol table info available.
*** Bug 420524 has been marked as a duplicate of this bug. ***
*** Bug 422899 has been marked as a duplicate of this bug. ***
*** Bug 423769 has been marked as a duplicate of this bug. ***
*** Bug 422957 has been marked as a duplicate of this bug. ***
*** Bug 425041 has been marked as a duplicate of this bug. ***
*** Bug 422231 has been marked as a duplicate of this bug. ***
*** Bug 418749 has been marked as a duplicate of this bug. ***
*** Bug 424849 has been marked as a duplicate of this bug. ***
*** Bug 428668 has been marked as a duplicate of this bug. ***
*** Bug 428654 has been marked as a duplicate of this bug. ***
*** Bug 430060 has been marked as a duplicate of this bug. ***
*** Bug 430366 has been marked as a duplicate of this bug. ***
*** Bug 430480 has been marked as a duplicate of this bug. ***
*** Bug 429849 has been marked as a duplicate of this bug. ***
*** Bug 433836 has been marked as a duplicate of this bug. ***
Created attachment 87237 [details] test file This bug can be easily reproduced using the attached source file, which produces the following backtrace: (gdb) bt
+ Trace 131276
I can recreate really easily this under GTK+ 2.10.11 on both Windows and amd64 linux. It seems to be as simple as calling specifying a filename in a path that doesn't exist to `gtk_file_chooser_set_filename()`.
Daniel, we appreciate if you would attach a small test program causing the crash. thanks.
Created attachment 87512 [details] [review] gtkfilechooser-crash.patch Back in February I added following patch to #397754 which fixed at least in my case, but it was marked as dupe against this bug. Readding, so it won't get lost...
(In reply to comment #103) > Daniel, we appreciate if you would attach a small test program causing the > crash. thanks. It turns out that the scenario is slightly different than what I thought. I can recreate it using the "test file" attachment using the following steps: -Set the filename in gtk_file_chooser_set_filename() to any file (this file doesn't even have to exist). (e.g. "/tmp/file.dat") -Set gtk_file_chooser_set_current_folder() to a completely different path (This needs to be an existing directory) (e.g. "/home/datallah/temp") Once these are set, simply running the program is enough to crash it. -D
*** Bug 439695 has been marked as a duplicate of this bug. ***
*** Bug 454162 has been marked as a duplicate of this bug. ***
(In reply to comment #104) > Created an attachment (id=87512) [edit] > gtkfilechooser-crash.patch > > Back in February I added following patch to #397754 which fixed at least in my > case, but it was marked as dupe against this bug. Readding, so it won't get > lost... > A very similar change was included in 2.10.12 and 2.11. It would be good to know if people are still seeing this crash with 2.10.12/13 or 2.11.
no reply from the submitter and no new duplicate, closed as fixed
*** Bug 424319 has been marked as a duplicate of this bug. ***
*** Bug 474268 has been marked as a duplicate of this bug. ***