GNOME Bugzilla – Bug 759608
"assertion failed" after finishing of copy directory
Last modified: 2015-12-20 02:32:25 UTC
When I try to copy a directory, it crashes after finishing the copy task, and throw the following error: ERROR:nautilus-directory-async.c:2351:count_more_files_callback: assertion failed: (directory->details->count_in_progress == state) Abgebrochen (Speicherabzug geschrieben) I'm using nautilus 3.18.3-1 from the arch repository
Here is the coresponding Stacktrace: systemd-coredump[4233]: Process 4206 (nautilus) of user 1000 dumped core. Stack trace of thread 4206: #0 0x00007f6d42f585f8 raise (libc.so.6) #1 0x00007f6d42f59a7a abort (libc.so.6) #2 0x00007f6d43dd18c5 g_assertion_message (libglib-2.0.so.0) #3 0x00007f6d43dd195a g_assertion_message_expr (libglib-2.0.so.0) #4 0x000000000049f2a6 n/a (nautilus) #5 0x00007f6d443118a7 n/a (libgio-2.0.so.0) #6 0x00007f6d44347413 n/a (libgio-2.0.so.0) #7 0x00007f6d44347449 n/a (libgio-2.0.so.0) #8 0x00007f6d43dabc7a g_main_context_dispatch (libglib-2.0.so.0) #9 0x00007f6d43dac020 n/a (libglib-2.0.so.0) #10 0x00007f6d43dac0cc g_main_context_iteration (libglib-2.0.so.0) #11 0x00007f6d4436b8ec g_application_run (libgio-2.0.so.0) #12 0x00000000004291b1 n/a (nautilus) #13 0x00007f6d42f45610 __libc_start_main (libc.so.6) #14 0x0000000000429219 n/a (nautilus) Stack trace of thread 4210: #0 0x00007f6d4300518d poll (libc.so.6) #1 0x00007f6d43dabfbc n/a (libglib-2.0.so.0) #2 0x00007f6d43dac0cc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f6d3420425d n/a (libdconfsettings.so) #4 0x00007f6d43dd2715 n/a (libglib-2.0.so.0) #5 0x00007f6d432d04a4 start_thread (libpthread.so.0) #6 0x00007f6d4300e13d __clone (libc.so.6) Stack trace of thread 4208: #0 0x00007f6d4300518d poll (libc.so.6) #1 0x00007f6d43dabfbc n/a (libglib-2.0.so.0) #2 0x00007f6d43dac342 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f6d443a2236 n/a (libgio-2.0.so.0) #4 0x00007f6d43dd2715 n/a (libglib-2.0.so.0) #5 0x00007f6d432d04a4 start_thread (libpthread.so.0) #6 0x00007f6d4300e13d __clone (libc.so.6) Stack trace of thread 4228: #0 0x00007f6d443b66d0 n/a (libgio-2.0.so.0) #1 0x00007f6d44311a10 n/a (libgio-2.0.so.0) #2 0x00007f6d44347bdd n/a (libgio-2.0.so.0) #3 0x00007f6d43dd30ae n/a (libglib-2.0.so.0) #4 0x00007f6d43dd2715 n/a (libglib-2.0.so.0) #5 0x00007f6d432d04a4 start_thread (libpthread.so.0) #6 0x00007f6d4300e13d __clone (libc.so.6) Stack trace of thread 4231: #0 0x00007f6d4300e101 __clone (libc.so.6)
Created attachment 317638 [details] [review] directory-async: don't modify priv data on cancelled What we are doing: Directory starts io. It cancels the cancellables associated to each async operation. It starts new operations. When the new operation finishes, either because it's cancelled or because it successfully finished, it modifies the directory private data and sets its associated cancellable as NULL to indicate the directory that it's all done, so the directory just checks for the cancellables in its private data to know if there is some operation going on. However, what can happens is: Directory starts io. It cancels the cancellables and sets as null to start a new operation. It starts a new operation. The old operation finishes cancelled, and sets as null the private cancellable of the directory. Now the directory thinks there is no operation going on, but actually the new operation is still going on. The directory starts io and checks if there is something to stop, but sees there is no cancellable and keeps going. Then the new operation finishes and hits an assert when realizes that the directory state is inconsistent. To fix this, don't set as null the cancellable in the private data of the directory when the operation has been cancelled, and instead check in the stop function if the operation was already cancelled. It's okay to set as null when the operation finishes succesfully, since it's ensured that only one operation can be running withouth being cancelled.
Created attachment 317640 [details] [review] directory-async: don't modify priv data on cancelled What we are doing: Directory starts io. It cancels the cancellables associated to each async operation. It starts new operations. When the new operation finishes, either because it's cancelled or because it successfully finished, it modifies the directory private data and sets its associated cancellable as NULL to indicate the directory that it's all done, so the directory just checks for the cancellables in its private data to know if there is some operation going on. However, what can happens is: Directory starts io. It cancels the cancellables and sets as null to start a new operation. It starts a new operation. The old operation finishes cancelled, and sets as null the private cancellable of the directory. Now the directory thinks there is no operation going on, but actually the new operation is still going on. The directory starts io and checks if there is something to stop, but sees there is no cancellable and keeps going. Then the new operation finishes and hits an assert when realizes that the directory state is inconsistent. To fix this, don't set as null the cancellable in the private data of the directory when the operation has been cancelled. It's okay to set as null when the operation finishes succesfully, since it's ensured that only one operation can be running withouth being cancelled.
Review of attachment 317640 [details] [review]: Looks good now thanks.
Thanks Cosimo!! Attachment 317640 [details] pushed as ec05b0a - directory-async: don't modify priv data on cancelled
*** Bug 759682 has been marked as a duplicate of this bug. ***