On Thu, Sep 24, 2015 at 02:22:10AM +0200, Stephan Beyer wrote: > I only checked for profile builds and first tried to bisect the issue, > which went terribly wrong because using older Git commits (unluckily I > can't say now how far you should go back in history), the test failed or > succeeded randomly. So it always found different (and always unrelated) > commits using "git bisect run". > However, in the latest versions, it *always* fails for a profile build > (and *never* for a non-profile build, at least here). > > Maybe this needs some more investigation? I don't think so. The tests have always been pretty solid, but I think the profile-build code was broken for a long while. > Hmm, but why is the profile build of http-backend "slower"? (Or am I > getting it wrong?) Remember that there are two phases to the profile build: first we build with profile-recording on, run the tests, and then build the optimized version with the output written during the test-run. And it's this first build that is failing the tests. I don't know exactly how the profile-recording is implemented, but I imagine that it records counters as it runs, and then after we call exit() it dumps the counters to a file. So the profile-generation version probably _is_ slower overall, but it is really the pause between exit() and the process actually ending that is the problem here (because the client thinks we are done and proceeds, but apache is waiting for the CGI to exit). > > Touching the apache logfile ourselves is inherently racy. > > It would not be racy if we started/stopped apache before/after each test > (and only append to the logfile after each apache shutdown). But that > would slow it down a lot. True, though that would be really slow (it may also still be racy; I don't know if Apache would flush out the log if it gets a shutdown signal or not). > That's a very good idea. (I just sent a patch with a possible realization.) Thanks, I'll give it a look. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html