GNOME Bugzilla – Bug 115263
Crash when recursing the main loop from "drag-begin"
Last modified: 2006-03-10 05:57:29 UTC
Package: nautilus Severity: normal Version: 2.2.1 Synopsis: file-roller crash Bugzilla-Product: nautilus Bugzilla-Component: File and Folder Operations BugBuddy-GnomeVersion: 2.0 (2.2.0.1) Description: Description of Problem: Bug buddy dialog appeared Steps to reproduce the problem: 1. I opened up a zip file, selected all the files 2. I dragged the files to another nautilus window Actual Results: bug buddy crash dialog Expected Results: no crash dialog How often does this happen? first time Additional Information: the combined size of the files in the zip file was very large, such that the unzip operation was taking many seconds. I am not sure if the unzip had completed when the crash occured. Debugging Information: Backtrace was generated from '/usr/bin/file-roller' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...[New Thread 1086198656 (LWP 10737)] 0xffffe002 in ?? ()
+ Trace 37838
Thread 1 (Thread 1086198656 (LWP 10737))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-06-15 21:07 ------- Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.
*** Bug 114131 has been marked as a duplicate of this bug. ***
*** Bug 115075 has been marked as a duplicate of this bug. ***
This is potentially a duplicate of bug 108166, but I'm not sure. I've marked all other duplicates I could find. I'm setting all fields appropriately, moving to gtk+ (one of the dups was also a file-roller crash, but the other was in gnome-panel), reassigning the bug to the owner of gtk+ and marking as new.
No, not a dup of bug 108166 - that isn't a crash at all.
(I think all the crashes are actually from the file-roller process, there is no nautilus connection here.) I can't reproduce this crash, but having looked at what file-roller is doing, I'm rather suprised that it even works at all. It's doing a expensive long operations from "drag-begin" and recursing the GTK+ main loop while doing so. The real fix is to fix file roller, and I've filed bug 119829 about that. As for GTK+, we probably should try to make GTK+ robust against this; though I'm not really sure how to do that. It may be that we can safely avoid calling ::drag-begin until we've set up almost everything for the drag other than the icon. (::drag-begin is just meant to allow people to set the icon for the drag, that's all!) Putting this on 2.4.0, since there are various reorganizations to the DND code base in HEAD which will make the situation different in head and gtk-2-2, so I think trying to fix it in both places is not sensible.
*** Bug 126381 has been marked as a duplicate of this bug. ***
*** Bug 128425 has been marked as a duplicate of this bug. ***
*** Bug 126717 has been marked as a duplicate of this bug. ***
*** Bug 138890 has been marked as a duplicate of this bug. ***
I don't think there is much for GTK+ to do here. The original file-roller issue has since been fixed.