GNOME Bugzilla – Bug 123051
dragging folders into a different folder caused a crash
Last modified: 2006-11-30 18:30:32 UTC
In the icon view, I dragged three folders in my home directory (names doen't seem to matter) named a,b, and c into a third folder named d. The drag completes successfully, but if the next action I perform is to double-click on d to open it, nautilus will crash. This seems to be 100% reproducible if I drag 3 or more folders into another. I don't see it if I drag only 1 or 2.
Created attachment 20217 [details] backtrace, such as it is...
I'm seeing a very similar crash on my system pretty often - but I can't reproduce it reliably. It always involves moving stuff around and then changing the selection in the sidebar tree. The instructions given here don't reproduce it for me unfortunately. Setting Priority->High, Severity->critical, adding STACKTRACE & GNOMEVER2.5 keywords. Setting Component to Sidebar Panel:Tree.
Reposting original stack trace inline to make searching easier. Backtrace was generated from '/usr/bin/nautilus' (no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[Thread debugging using libthread_db enabled] [New Thread -1085185920 (LWP 6655)] [New Thread 12585904 (LWP 6660)] [New Thread 11983792 (LWP 6659)] [New Thread 11410352 (LWP 6658)] [New Thread 8403888 (LWP 6657)] [New Thread 15244208 (LWP 6656)] (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... 0x00185c02 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
+ Trace 40486
Thread 1 (Thread -1085185920 (LWP 6655))
This is one of my stack traces: Backtrace was generated from '/usr/bin/nautilus' [New Thread 1089429376 (LWP 4540)] [New Thread 1102310320 (LWP 5361)] [New Thread 1102044080 (LWP 5360)] [New Thread 1101777840 (LWP 5359)] [New Thread 1101478832 (LWP 5290)] [New Thread 1095056304 (LWP 4548)] [New Thread 1093872560 (LWP 4545)] [New Thread 1093606320 (LWP 4544)] [New Thread 1093340080 (LWP 4543)] [New Thread 1093073840 (LWP 4542)] [New Thread 1092807600 (LWP 4541)] 0xffffe410 in ?? ()
+ Trace 40487
Thread 1 (Thread 1089429376 (LWP 4540))
*** Bug 125073 has been marked as a duplicate of this bug. ***
I have fixed the crash, and attaching a patch. I am not very sure that , this is 'THE' fix. It could also be a workaround. There was a problem with the sorting, when the folder is opened. It dumps in the comparision function 'gtk_tree_model_sort_compare_func()' When i debugged, in the gqsort.c g_qsort_with_data, it went behind the base pointer and passes the function some junk data. I put a filter constraint, to make sure that it is between base_ptr and (base_ptr+size). It fixed the problem and worked. It is a patch in glib/glib/gqsort.c If the patch is wrong, you can proceed from the point , gtktreemodelsort.c:gtk_tree_model_sort_sort_level (), from where all the sorting operations are carried forward.
Created attachment 21264 [details] [review] Fixes the gqsort.c:g_qsort_with_data, where it sorts the folder
*** Bug 129037 has been marked as a duplicate of this bug. ***
Srinivasa, can you still duplicate the bug? I can't. I took a look at your patch. If the rest of the quicksort algorithm is implemented properly, and if the scan through the first threshold for the lowest value is correct, then the only way I can see the problem occuring is if compare_func has been implemented in such as way as to return different values for the same comparison done at different times. That seems to be the only way that a comparison between base_ptr[0] and base_ptr[1] can cause tmp_ptr to underflow in the insertion sort - basically, base_ptr[0] has to end up holding a value that isn't the lowest value in the array. I would think this would be a problem in the tree view, or perhaps its creator. I can't duplicate this using the method that I described any more, now that I've tried again with Fedora Core 1 (plus updates). I'd close the bug, were it not that Bug #129037 was apparently filed with FC1 as well. From the changelog on the gtk2 RPM I've got, it doesn't seem like much would have changed since I filed the report (probably was using gtk 2.2.4-3.0 (fedora rev) at that point.
the glib change doesn't fix the root cause, removing PATCH.
*** Bug 125402 has been marked as a duplicate of this bug. ***
*** Bug 133657 has been marked as a duplicate of this bug. ***
*** Bug 134375 has been marked as a duplicate of this bug. ***
*** Bug 134374 has been marked as a duplicate of this bug. ***
*** Bug 145677 has been marked as a duplicate of this bug. ***
*** Bug 146049 has been marked as a duplicate of this bug. ***
No dups with Nautilus > 2.4, marking NEEDINFO for now.
*** Bug 156486 has been marked as a duplicate of this bug. ***
bug 156486 occured on GNOME-2.6, so bumping Version => 2.6.
no dups since GNOME 2.6, bug closed.
*** Bug 170156 has been marked as a duplicate of this bug. ***
*** Bug 169096 has been marked as a duplicate of this bug. ***
Dups with 2.8/2.9 -> reopening & adjusting versions.
*** Bug 160430 has been marked as a duplicate of this bug. ***
*** Bug 302675 has been marked as a duplicate of this bug. ***
*** Bug 301611 has been marked as a duplicate of this bug. ***
*** Bug 302775 has been marked as a duplicate of this bug. ***
*** Bug 303817 has been marked as a duplicate of this bug. ***
*** Bug 167157 has been marked as a duplicate of this bug. ***
*** Bug 304780 has been marked as a duplicate of this bug. ***
George: It would be great if you could take a look at gqsort.c again. This problems seems to be very widespread, even in recent versions.
Created attachment 46714 [details] test case for patch OK, now that I look at it, in any case, g_qsort_with_data must not dereference pointers outside the bounds of the input array passed in by the caller. Since it's doing that in this case, there's got to be a bug in both the caller for specifying a compare function that isn't really sorting the array. So I think the patch or some variant of it should be applied, although there's got to be a bug elsewhere in the compare function, which I haven't tried to hunt down. I'm not sure that the patch should just silently ignore the problem. Asserting an error (which still causes termination) or at least issues a warning might be better choices. There's no hint in the definition of qsort to use for error handling. I've attached a test case to show how a broken compare function (one that always returns the same result regardless of the input) can cause this sort function to attempt to dereference out of bounds memory.
Amend the end of the first paragraph in to "Since it's doing that in this case, there's got to be a bug in both g_qsort_with_data and in the caller (for specifying a compare function that isn't really sorting the array)."
*** Bug 169351 has been marked as a duplicate of this bug. ***
*** Bug 305239 has been marked as a duplicate of this bug. ***
*** Bug 305571 has been marked as a duplicate of this bug. ***
I use nautilus to sort images. Moving 800+ source images from one directory into 4-5 directories. Move to trash is also performed. Nautilus crashes after working with 200-300 images. Restarting the X server appears to cause nautilus to live longer after a crash then just restarting the application.
*** Bug 306255 has been marked as a duplicate of this bug. ***
*** Bug 307263 has been marked as a duplicate of this bug. ***
*** Bug 307453 has been marked as a duplicate of this bug. ***
*** Bug 307462 has been marked as a duplicate of this bug. ***
*** Bug 308147 has been marked as a duplicate of this bug. ***
*** Bug 171705 has been marked as a duplicate of this bug. ***
*** Bug 310943 has been marked as a duplicate of this bug. ***
There is a possible cause for this in fm-tree-view.c:compare_rows(). It doesn't seem to correctly sort the dummy row. compare(dummy, *) and compare(*, dummy) both return -1. I'm attaching a patch that fixes this. However, I'm not sure this is the real problem, because this should only affect things when the dummy row is sorted against real files, and we remove the dummy row whenever we add another row.
Created attachment 51612 [details] [review] fix for dummy row sorting
*** Bug 317595 has been marked as a duplicate of this bug. ***
*** Bug 316718 has been marked as a duplicate of this bug. ***
I commited the last patch. It might work, we'll have to see if duplicates stop comming in after: 2005-09-30 Alexander Larsson <alexl@redhat.com> * src/file-manager/fm-tree-view.c: (compare_rows): Correct sort order for dummy row. Possible fix for #123051
This is rather magical for a non developper like me : just changing -1 to 1 !! :-) Does it mean this should work for nautilus 2.10 too ?
oll: We ceased to support Nautilus 2.10 when we released 2.12. However, you can ask your distributor to use this patch for GNOME 2.10. Only time will tell whether it helps, though.
Yes, that's precisely why I asked this question . I installed garnome 2.10.2 for all my users and I used to apply patches (In one way, I'm my own distributor :-) ). I just wanted to know If this patch is "backportable" to 2.10.
Yes, it is definitly applicable. While this change seemed to be trivial it actually fixed a bad sort compare function. Search algorithms often rely on the assumption that their compare function returns the a value with a swapped sign [1] for swapped input data, i.e. a > b <=> b < a, in this case compare_rows (a, b) == compare_rows (b,a) [1] http://en.wikipedia.org/wiki/Trichotomy
*** Bug 318812 has been marked as a duplicate of this bug. ***
This is almost certainly fixed by now - If it isn't, we'll find out soon enough. I think it was related to bug 158506.
*** Bug 380937 has been marked as a duplicate of this bug. ***