GNOME Bugzilla – Bug 389760
freeze nautilus when copying a directory to burn: location
Last modified: 2008-02-17 01:38:57 UTC
That bug has been described on https://launchpad.net/distros/ubuntu/+source/nautilus-cd-burner/+bug/72284 "... Okay, it's not any large directory that causes a problem. But this one (untar it), drag directory into burner seems a robust crash: http://grad.econ.ubc.ca/cpbl/tmp/2000.tgz I did as you asked while the windows were unresponsive: (gdb) thread apply all bt
+ Trace 97093
Other Ubuntu bug about that: https://launchpad.net/ubuntu/+source/nautilus-cd-burner/+bug/69411 "... http://librarian.launchpad.net/5765022/gdb-nautilus-cd-burner.txt gdb backtrace of hung nautilus-cd-burner process ...
+ Trace 102633
seeing similar problem on opensolaris 2.19 x64 copying 400 x 1 Mb files to burn folder in nautilus 811: nautilus --no-default-window --sm-client-id default2 ----------------- lwp# 1 / thread# 1 -------------------- fef3e5d7 pollsys (8045b10, 1, 8045c58, 0) feef88ae pselect (1b, 8046ca0, fef884d8, fef884d8, 8045c58, 0) + 19e feef8bbe select (1b, 8046ca0, 0, 0, 8045c98) + 7e faa25501 mapping_protocol_channel_fill_read_buffer_unlocked (82e9048, 1) + 9d faa25754 mapping_protocol_channel_do_read_iteration_unlocked (82e9048, 1) + 20 faa2534d mapping_protocol_channel_send_with_reply (82e9048, c0ca2e0, 8046de4) + dd faa22d44 request_op (7, b5a4058, b5a4068, 0, 0, 0) + 68 faa23102 do_open_directory (faa362f8, 8046e28, c0e50c8, 0, 0) + 52 fe5b21f4 open_from_uri (8046e94, c0e50c8, 0, 0) + 48 fe5b22e8 gnome_vfs_directory_open (8046e94, fb204350, 0) + 4c fb203a79 dir_is_empty (fb204350) + 25 fb203cac update_empty_idle (81ea600) + 2c fe49af5b g_idle_dispatch (8ab3950, fb203c80, 81ea600) + 1f fe497cf6 g_main_dispatch (81be9f8) + 1e2 fe498e05 g_main_context_dispatch (81be9f8) + 85 fe499222 g_main_context_iterate (81be9f8, 1, 1, 819acb8) + 3ce fe499824 g_main_loop_run (820df68) + 1b8 fe793c92 gtk_main (8047374, 8047254, feffa7d0, 0, 0, 8166964) + b2 080b6c7a main (4, 8047298, 80472ac) + 8b6 080a5b32 _start (4, 80473dc, 80473e5, 80473f9, 8047408, 0) + 7a ----------------- lwp# 16 / thread# 16 -------------------- fef3eb87 waitid (0, 80e, f69a3d50, 3) fef31f46 waitpid (80e, f69a3eb4, 0) + 70 fe4c5b96 g_spawn_sync (0, c05cfc0, 0, 4, 0, 0) + 346 fe4c5f4a g_spawn_command_line_sync (c0e2808, 0, 0, f69a3f8c, 0) + 5a fe137bc4 gnome_thumbnail_factory_generate_thumbnail (8283f00, 92c1540, 92e20e8) + 394 0814bdf6 thumbnail_thread_start (0) + 166 fef3d952 _thr_setup (faa61200) + 52 fef3dbb0 _lwp_start (faa61200, 0, 0, 0, 0, 0) ----------------- lwp# 25 / thread# 25 -------------------- fef3dbeb lwp_park (0, 0, 0) fef37cf6 cond_wait_queue (c037c88, c024f28, 0, 0) + 41 fef381da _cond_wait (c037c88, c024f28) + 69 fef38218 cond_wait (c037c88, c024f28) + 24 fef38252 pthread_cond_wait (c037c88, c024f28) + 1e fe5b6401 job_notify (c060400, f79fdd20) + 55 fe5b7853 xfer_callback (f79fddd0, c060400) + 43 fe5cbfd6 call_progress (f79fdd9c, 10) + 62 fe5cf24f _gnome_vfs_xfer_private (c0938d0, c097110, 608, 1, 1, fe5b7810) + 4e3 fe5b7ab6 _gnome_vfs_job_execute (c060400, c060400, 81e8b10, fe525398, fe47935b, 81da250) + 25a fe5b5ffe thread_entry_point (c060400, 0) + 56 fe4ba433 g_thread_pool_thread_proxy (81e8b10) + b3 fe4b8fd2 g_thread_create_proxy (c098f00) + 11a fef3d952 _thr_setup (faa60200) + 52 fef3dbb0 _lwp_start (faa60200, 0, 0, 0, 0, 0) -bash-3.00$
I encountered the bug as well when trying to drag a directory containing about 1600 files into the burn folder. I think this is very similar to bug number 466013
I get a slightly different stack trace than Robert did. This stack trace suggests that it is a prtoblem with lock contention. It looks like thread 14 has grabbed channel_lock and two other threads are waiting on it. ash-3.2$ pstack `pgrep nautilus` 14132: nautilus --sm-client-id 11819ce2f7000119451200400000008660015 --screen ----------------- lwp# 1 / thread# 1 -------------------- feefe8eb lwp_park (0, 0, 0) feef77c3 mutex_lock_impl (f69f6374, 0) + f3 feef7852 mutex_lock (f69f6374) + 10 f69e5857 handle_write (83de268, 4, 83de230) + 7b fe4b4b97 g_io_unix_dispatch (8aded60, f69e57dc, 83de230) + 3b fe487c3a g_main_dispatch (81c0ea8) + 1e2 fe488d49 g_main_context_dispatch (81c0ea8) + 85 fe489166 g_main_context_iterate (81c0ea8, 1, 1, 819c560) + 3ce fe489768 g_main_loop_run (81e8408) + 1b8 fe77b222 gtk_main (8046dc0, 8046c64, feffa7d8, 6e6f6200, 8046aa0, 8167fe8) + b2 080b73ce main (5, 8046ca8, 8046cc0) + 8b6 080a6072 _start (5, 8046e28, 8046e31, 8046e40, 8046e66, 8046e6f) + 7a ----------------- lwp# 13 / thread# 13 -------------------- feefe8eb lwp_park (0, 0, 0) feef77c3 mutex_lock_impl (f69f6374, 0) + f3 feef7852 mutex_lock (f69f6374) + 10 f69e4e99 mapping_protocol_channel_send_internal (83de230, 8c24900) + 69 f69e52ab mapping_protocol_channel_send_with_reply (83de230, 8c24900, f65fde24) + 3b f69e2d44 request_op (0, 8c22280, 8b38098, 0, 0, 0) + 68 f69e344a do_get_file_info (f69f62f8, 8c228d8, 8c24778, d9, 8c222a0) + 4a fe5afce9 gnome_vfs_get_file_info_uri_cancellable (8c228d8, 8c24778, d9, 8c222a0) + 6d fe5b7a46 _gnome_vfs_job_execute (8609c50, 8609c50, 81c2c68, fe51759c, fe46933b, 81c13f0) + 1ea fe5b5ffe thread_entry_point (8609c50, 0) + 56 fe4aa20b g_thread_pool_thread_proxy (81c2c68) + b3 fe4a8d92 g_thread_create_proxy (8c1bd20) + 11a feefe652 _thr_setup (fa470a00) + 52 feefe8b0 _lwp_start (fa470a00, 0, 0, 0, 0, 0) ----------------- lwp# 12 / thread# 12 -------------------- feefe8eb lwp_park (0, 0, 0) feef8a06 cond_wait_queue (8ac75a8, 8a578a8, 0, 0) + 41 feef8eea _cond_wait (8ac75a8, 8a578a8) + 69 feef8f28 cond_wait (8ac75a8, 8a578a8) + 24 feef8f62 pthread_cond_wait (8ac75a8, 8a578a8) + 1e fe5b6401 job_notify (886ed98, f5606d20) + 55 fe5b7853 xfer_callback (f5606dd0, 886ed98) + 43 fe5cbfd6 call_progress (f5606d9c, 10) + 62 fe5cf24f _gnome_vfs_xfer_private (8b38370, 8b3dac0, 608, 1, 1, fe5b7810) + 4e3 fe5b7ab6 _gnome_vfs_job_execute (886ed98, 886ed98, 81c2c68, fe51759c, fe46933b, 81c13f0) + 25a fe5b5ffe thread_entry_point (886ed98, 0) + 56 fe4aa20b g_thread_pool_thread_proxy (81c2c68) + b3 fe4a8d92 g_thread_create_proxy (8b43000) + 11a feefe652 _thr_setup (fa471a00) + 52 feefe8b0 _lwp_start (fa471a00, 0, 0, 0, 0, 0) ----------------- lwp# 14 / thread# 14 -------------------- fef022e7 pollsys (f57fcb00, 1, f57fcc38, 0) feeb956e pselect (18, f57fdc80, fef964e0, fef964e0, f57fcc38, 0) + 19e feeb987e select (18, f57fdc80, 0, 0, f57fcc78) + 7e f69e5501 mapping_protocol_channel_fill_read_buffer_unlocked (83de230, 1) + 9d f69e5750 mapping_protocol_channel_do_read_iteration_unlocked (83de230, 1) + 20 f69e534d mapping_protocol_channel_send_with_reply (83de230, 8c24438, f57fddc4) + dd f69e2d44 request_op (7, 8c222b0, 8c222f0, 0, 0, 0) + 68 f69e3102 do_open_directory (f69f62f8, f57fde00, 8c22a10, 20, 8c1b160) + 52 fe5b21f4 open_from_uri (f57fde74, 8c22a10, 20, 8c1b160) + 48 fe5b2436 gnome_vfs_directory_open_from_uri_cancellable (f57fde74, 8c22a10, 20, 8c1b160) + 32 fe5b767b load_directory_details (8b74bf0) + 3f fe5b7c0e _gnome_vfs_job_execute (8b74bf0, 8b74bf0, 81c2c68, fe51759c, fe46933b, 81c13f0) + 3b2 fe5b5ffe thread_entry_point (8b74bf0, 0) + 56 fe4aa20b g_thread_pool_thread_proxy (81c2c68) + b3 fe4a8d92 g_thread_create_proxy (8c1b720) + 11a feefe652 _thr_setup (fa471200) + 52 feefe8b0 _lwp_start (fa471200, 0, 0, 0, 0, 0)
I am seeing a call to mapping_protocol_channel_dispatch_unlocked in the mapping daemon try to write 62893 bytes but the write syscall returns EAGAIN and only 30705 bytes were written. The remaining data is never written. The nautilus process is waiting for this data.
Created attachment 98841 [details] [review] possible fix Thanks for looking into this. Does something like this help?
I've committed this: http://svn.gnome.org/viewvc/nautilus-cd-burner?view=revision&revision=2103 To 2.20/trunk. Does this help?
This fix works for me. Thanks.
Not quite. The copying to the cd burner passes off successfully. I then attempted to move all the files on the cd burner to Trash and nautilus hung with a similar problem. bash-3.2# pstack `pgrep nautilus` 3139: nautilus ----------------- lwp# 1 / thread# 1 -------------------- feefe8eb lwp_park (0, 0, 0) feef77c3 mutex_lock_impl (f6876374, 0) + f3 feef7852 mutex_lock (f6876374) + 10 f6865857 handle_write (83e6900, 4, 83e68c8) + 7b fe4b4c1f g_io_unix_dispatch (8fe2388, f68657dc, 83e68c8) + 3b fe487cc2 g_main_dispatch (81c0e78) + 1e2 fe488dd1 g_main_context_dispatch (81c0e78) + 85 fe4891ee g_main_context_iterate (81c0e78, 1, 1, 819c560) + 3ce fe4897f0 g_main_loop_run (81e8d00) + 1b8 fe77a9c2 gtk_main (8046d9c, 8046c40, feffa7d8, 6e6f6200, 8046a80, 8167fe8) + b2 080b73ce main (1, 8046c84, 8046c8c) + 8b6 080a6072 _start (1, 8046e04, 0, 8046e0d, 8046e45, 8046e5c) + 7a ----------------- lwp# 16 / thread# 16 -------------------- feefe8eb lwp_park (0, 0, 0) feef77c3 mutex_lock_impl (f6876374, 0) + f3 feef7852 mutex_lock (f6876374) + 10 f6864e99 mapping_protocol_channel_send_internal (83e68c8, 8fe4fa8) + 69 f68652ab mapping_protocol_channel_send_with_reply (83e68c8, 8fe4fa8, f5dfdc94) + 3b f6862d44 request_op (0, 8fa0ce0, 8c30b60, 0, 0, 0) + 68 f686344a do_get_file_info (f68762f8, 8fa7030, 8f18088, 0, 0) + 4a fe5afce9 gnome_vfs_get_file_info_uri_cancellable (8fa7030, 8f18088, 0, 0) + 6d fe5c13a3 gnome_vfs_get_file_info_uri (8fa7030, 8f18088, 0) + 23 fe5ce5fb gnome_vfs_xfer_delete_items_common (8f47a90, 1, 28, f5dfdd9c) + 53 fe5ce702 gnome_vfs_xfer_delete_items (8f47a90, 1, 28, f5dfdd9c) + 7e fe5cf0fb _gnome_vfs_xfer_private (8f47a90, 0, 28, 1, 2, fe5b7810) + 38f fe5b7ab6 _gnome_vfs_job_execute (8f83670, 8f83670, 81c2560, fe51768c, fe46933b, 81c12b0) + 25a fe5b5ffe thread_entry_point (8f83670, 0) + 56 fe4aa293 g_thread_pool_thread_proxy (81c2560) + b3 fe4a8e1a g_thread_create_proxy (8f4cf48) + 11a feefe652 _thr_setup (fa491200) + 52 feefe8b0 _lwp_start (fa491200, 0, 0, 0, 0, 0) ----------------- lwp# 17 / thread# 17 -------------------- fef022e7 pollsys (f69fcb00, 1, f69fcc38, 0) feeb956e pselect (18, f69fdc80, fef964e0, fef964e0, f69fcc38, 0) + 19e feeb987e select (18, f69fdc80, 0, 0, f69fcc78) + 7e f6865501 mapping_protocol_channel_fill_read_buffer_unlocked (83e68c8, 1) + 9d f6865750 mapping_protocol_channel_do_read_iteration_unlocked (83e68c8, 1) + 20 f686534d mapping_protocol_channel_send_with_reply (83e68c8, 8fe1a08, f69fddc4) + dd f6862d44 request_op (7, 8fe0d70, 8fe0d90, 0, 0, 0) + 68 f6863102 do_open_directory (f68762f8, f69fde00, 8fe1920, 20, 8fe0cf0) + 52 fe5b21f4 open_from_uri (f69fde74, 8fe1920, 20, 8fe0cf0) + 48 fe5b2436 gnome_vfs_directory_open_from_uri_cancellable (f69fde74, 8fe1920, 20, 8fe0cf0) + 32 fe5b767b load_directory_details (8f83530) + 3f fe5b7c0e _gnome_vfs_job_execute (8f83530, 8f83530, 81c2560, fe51768c, fe46933b, 81c12b0) + 3b2 fe5b5ffe thread_entry_point (8f83530, 0) + 56 fe4aa293 g_thread_pool_thread_proxy (81c2560) + b3 fe4a8e1a g_thread_create_proxy (8fe19d8) + 11a feefe652 _thr_setup (fa490a00) + 52 feefe8b0 _lwp_start (fa490a00, 0, 0, 0, 0, 0)
I have also found that the copying to the cd burner still intermittently hangs with stack trace bash-3.2$ pstack `pgrep nautilus` 6348: nautilus ----------------- lwp# 1 / thread# 1 -------------------- feefe8eb lwp_park (0, 0, 0) feef77c3 mutex_lock_impl (f6866374, 0) + f3 feef7852 mutex_lock (f6866374) + 10 f6855857 handle_write (83e6900, 4, 83e68c8) + 7b fe4b4bab g_io_unix_dispatch (8fe92a0, f68557dc, 83e68c8) + 3b fe487c4e g_main_dispatch (81c0e78) + 1e2 fe488d5d g_main_context_dispatch (81c0e78) + 85 fe48917a g_main_context_iterate (81c0e78, 1, 1, 819c560) + 3ce fe48977c g_main_loop_run (81e8d00) + 1b8 fe77a9c2 gtk_main (8046d9c, 8046c40, feffa7d8, 6e6f6200, 8046a80, 8167fe8) + b2 080b73ce main (1, 8046c84, 8046c8c) + 8b6 080a6072 _start (1, 8046e04, 0, 8046e0d, 8046e45, 8046e5c) + 7a ----------------- lwp# 13 / thread# 13 -------------------- fef022e7 pollsys (f5dfcb00, 1, f5dfcc38, 0) feeb956e pselect (18, f5dfdc80, fef964e0, fef964e0, f5dfcc38, 0) + 19e feeb987e select (18, f5dfdc80, 0, 0, f5dfcc78) + 7e f6855501 mapping_protocol_channel_fill_read_buffer_unlocked (83e68c8, 1) + 9d f6855750 mapping_protocol_channel_do_read_iteration_unlocked (83e68c8, 1) + 20 f685534d mapping_protocol_channel_send_with_reply (83e68c8, 8ff48d0, f5dfddc4) + dd f6852d44 request_op (7, 8ff5f68, 8ff5f28, 0, 0, 0) + 68 f6853102 do_open_directory (f68662f8, f5dfde00, 8f5bf98, 20, 8ff4b80) + 52 fe5b21f4 open_from_uri (f5dfde74, 8f5bf98, 20, 8ff4b80) + 48 fe5b2436 gnome_vfs_directory_open_from_uri_cancellable (f5dfde74, 8f5bf98, 20, 8ff4b80) + 32 fe5b767b load_directory_details (8f42800) + 3f fe5b7c0e _gnome_vfs_job_execute (8f42800, 8f42800, 81c2560, fe5175a4, fe46933b, 81c12b0) + 3b2 fe5b5ffe thread_entry_point (8f42800, 0) + 56 fe4aa21f g_thread_pool_thread_proxy (81c2560) + b3 fe4a8da6 g_thread_create_proxy (897db78) + 11a feefe652 _thr_setup (fa491200) + 52 feefe8b0 _lwp_start (fa491200, 0, 0, 0, 0, 0)
Ok two more patches in SVN. I think we may have it. Thanks for your help and analysis! Please reopen if it isn't fixed.
I needed to change the return statement return (status == G_IO_STATUS_NORMAL); to if (status == G_IO_STATUS_NORMAL || status == G_IO_STATUS_AGAIN) return TRUE; else return FALSE; Otherwise I cannot open the Burn Folder.
OK fixed in SVN. Thanks!
*** Bug 396642 has been marked as a duplicate of this bug. ***
*** Bug 516715 has been marked as a duplicate of this bug. ***