On Mar 03, 2014, at 08:44 AM, Alan Pope ㋛ wrote: >I have triggered it again on 216 upgrading to 217. > >To be clear, I'm *not* upgrading, but starting the upgrade then pressing >back, then going back in later, and then the error appears. Here's a >video:- > >https://www.youtube.com/watch?v=YmD6cGYvIAI
One difference from the previous incarnation is that you're doing manual downloads. Your video actually helped quite a bit as I can reproduce this fairly consistently now by flashing to 215 and upgrading to whatever is the latest image. Log file analysis leads me to think there's a race condition between u-d-m doing its atomic renames and it sending the 'finished' signal for the group download. If I put some logging right after the finished signal is received, and I list the directories containing the destination files, I see that they have .tmp.tmp suffixes. The first .tmp is put there by s-i (which still has its own atomic-rename workaround), but the second .tmp is put there by u-d-m for *its* atomic rename operation. It should not be possible for s-i to see the .tmp.tmp files. This can only happen if it's seeing the finished signal before u-d-m does its atomic rename. I tried the following experiment: at the point where the finished signal is received, I log the data as explained above, and then I sleep(2) before continuing on. With the sleep in there, it doesn't crash for me. This isn't definitive proof of what's going on, but it seems plausible. Manuel is investigating u-d-m, and then he'll provide a package for me to test on my device. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1277589 Title: Better protection against concurrent access To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-download-manager/+bug/1277589/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
