GNOME Bugzilla – Bug 706456
pull is still racy
Last modified: 2014-02-21 20:14:51 UTC
I haven't debugged this, but it appears to happen occasionally on the loaded build server. The original commit was: https://git.gnome.org/browse/ostree/commit/?id=5c1dc390ae0e51487f9451fe433f76461f4c4127 Then some follow up fixes which helped but didn't quite fix it: https://git.gnome.org/browse/ostree/commit/?id=9bd4d35c2b34a321c9da2ad115b113076366a146 https://git.gnome.org/browse/ostree/commit/?id=efe27f1b05eb9aa4a3760951885c2eca78d6516f
Created attachment 266688 [details] race I caught an instance of this in action with newly added debugging prints. We can see here that the problem is that there are pending content requests in flight from the metadata scan thread to the main thread, but the main thread has received idle status and chosen to exit.
Going to mark this one closed, will reopen if it reoccurs. https://git.gnome.org/browse/ostree/commit/?id=3cd866556c1163128ca2310d38fb4e3cd43d39e2
Sadly, still happening =( Workaround: $ ln -s blah /ostree/repo/transaction $ rm /ostree/repo/refs/remotes -rf Then do a pull again.
*** Bug 724115 has been marked as a duplicate of this bug. ***
Created attachment 269936 [details] [review] pull: Remove explicit threading Mixing async and threads has proved to be too much for my little mind. It has race conditions that I've tried repeatedly to fix, but failed. The threading here was scanning metadata objects - and there are two parts to that: 1) Physically loading them from disk 2) Parsing them Now #1 has been partially addressed by avoiding a storm of lstat() if we're starting from a known working state. If pull gets interrupted, then we do need to rescan all objects. Also, we can address this with local metadata packfiles. deep recursion though while we also have outstanding HTTP. Anyways, let's move the needle back to reliability, and readd speed more carefully.
Looks ok to me, the one thing that did confuse me for a while is that the phase variable implicitely is set to OSTREE_PULL_PHASE_FETCHING_REFS (by assuming the first enum field will be 0).
Good point, fixed. Anything to make this code clearer for the inevitable time when I have to debug it two years on and I've forgotten how it works... Thanks for looking at this! https://git.gnome.org/browse/ostree/commit/?id=b762c2f8f1f0245d4994864f0fa8d9ac1ba261b8