On Tue, Jun 9, 2015 at 6:02 PM, Greg Bedwell <[email protected]> wrote: >> >> Remove rm invocations where the file is immediately rewritten later. >> >> This may or may not help making this test less flaky on windows. There's >> a race condition in lit somewhere. >> > > I've always assumed that this is just Windows holding onto the file for too > long, possibly exacerbated by the presence of AV software, rather than an > issue with lit itself although I'm just wildly speculating based on previous > experience with this sort of thing. I'm still hitting this failure on my > machine occasionally today after this commit although I'll have to use it > for a few days more before deciding whether it reduces the frequency of the > failure or not. > > If it really is just a Windows thing rather than a lit thing I'm not sure > what we'd be able to do beyond something like having lit intercept calls to > rm and perform some sort of retry method for permission errors on Windows. > I'm pretty sure that will work, but it's extremely nasty, and if the problem > is more heinous than just Windows holding onto files it's not a real fix > either. > > Thanks for having looked at this either way though! It's a relief to know > it's not just me that keeps running into this one.
Right, it's still failing intermittently :( Indexer/AV seems like a more likely explanation and one that's going to be hard to fix. Just working around 'rm' would fix this specific tests, but there are others (archive-update.test) that also fail on windows from time to time and that one seems unrelated to rm. I rarely run tests on windows myself (takes forever) but I want the buildbots to stop yelling at me ... - Ben _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
