GNOME Bugzilla – Bug 396642
nautilus-cd-burner hangs on startup
Last modified: 2008-01-21 02:01:07 UTC
Please describe the problem: After pasting the directoies I need to burn into the CD/DVD Creator Nautilus window, I press the "Write to Disc" button. The natutilu-cs-buriner starts up with all control grayed out, saying "Calculating size..." and it remains like that indefinitely. In fact, it hangs hard without being able to refresh the screen (invalidating the window will result in a gray window), without any sign of CPU usage. Steps to reproduce: 1. Paste files in the "CD/DVD Creator Nautilus" window 2. Click the "Write to Disc" button 3. Watch nautilus-cd-burner just sit there Actual results: Nothing much, the app will no longer respond to input or be able to redraw its screen. Expected results: To actually burn the DVD :) Does this happen every time? Yes. Other information: Here is a backtrace of the nautilus-cd-burner process:
+ Trace 102203
More information: after clicking on the "X" top-right window button, I get the "Force Quit" dialog. I kill the app, but then Nautilus can no longer display the files in the "CD/DVD Creator" window, complaining that: Nautilus cannot display "burn:///". Please select another viewer and try again. From now on I always get this error whenever I try to access the "CD/DVD Creator". I have to kill(1) nautilus to recover from this state.
There's more to the story: if I paste just two small directories (<4MB worth of data), nautilus-cd-burner apps starts up as expected. However, if I add the 3rd directory that is a lot bigger (3.3 GB), it misbehaves as described above, with all the controls grayed out, displaying: Data Size: Calculating... I know I used nautilus-cd-burner to burn DVDs that were almost full, I don't understand why it stoped working all of a sudden. Here is another backtrace of this latest misbevaving process:
+ Trace 102209
It turns out that the problematic directory contains a lot of file: 178163. I was able to burn DVD that contain the same amount of data (>3GB) but with few large files without a problem. So it seems this has to do with the file count, not file size.
I'm having a hard time reproducing this because I can't even get nautilus to display a directory with 178163 files. It is possible that it may just take an extremely long time. But if it is interrupted then it is possible that nautilus/gnome-vfs is put in an inconsistent state. Killing nautilus will cause it to disconnect from the mapping daemon and the daemon should reset. What kind of directory has this many files in it? One thing you can do help debug is compile n-c-b from source and set "#define DEBUG_ENABLE 1" in mapping-daemon.c mapping-protocol.c and mapping-method.c. You can then do something like: strace -ttt -f -p `/sbin/pidof mapping-daemon` 2>&1 |grep MARK strace -ttt -f -p `/sbin/pidof nautilus` 2>&1 |grep MARK
It is not a single directory with 178163 files, it's my devel/ tree with all sorts of subdirs and files. Essentially the 178163 is what is reported by: $ find devel/ -type f | wc -l You may get a similar amount of files from /usr: $ find /usr -type f | wc -l 169072
I have the same problem, but with less files. I have just less than 2000 files, but almost exactly 4.7GB. Here is my backtrace:
+ Trace 104130
If anyone can reproduce this and perform the steps in comment #4 that would be a big help. Thanks.
I tried the steps in comment #4, but I'm currently running into a problem when adding the files (~1700, 4.6GB). Nautilus appears to lock up, with the following backtrace:
+ Trace 104428
strace output (using command options above) on nautilus gives the following repeating block: [pid 29945] 1169506111.836404 access("MARK: nautilus mapping_protocol_channel_fill_read_buffer_unlocked: No data read into buffer", F_OK) = -1 ENOENT (No such file or directory) [pid 29945] 1169506111.836505 access("MARK: nautilus mapping_protocol_channel_queue_messages_unlocked: Queuing messages...", F_OK) = -1 ENOENT (No such file or directory) [pid 29945] 1169506111.836578 access("MARK: nautilus mapping_protocol_channel_queue_messages_unlocked: Processing message of type: R", F_OK) = -1 ENOENT (No such file or directory) [pid 29945] 1169506111.837858 access("MARK: nautilus lookup_reply_for_serial: Looking for reply for 6273", F_OK) = -1 ENOENT (No such file or directory) [pid 29945] 1169506111.838422 access("MARK: nautilus mapping_protocol_channel_fill_read_buffer_unlocked: Reading... ", F_OK) = -1 ENOENT (No such file or directory)
I think I can confirm this in RHEL5 x86_64. That's version 2.16.0-7.el5. We dragged a directory with 143751 files in it and the cd burner window became unresponsive. We eventually killed it but after restarting the folder still cannot be deleted from the burn:/// window. We tried dragging it to the trash but after 90 minutes the app was still frozen. Can anyone tell me which keys/files/links to delete to reset things for this user account? For now the application is useless for this user. - Bill
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 389760 ***