On Wed, Feb 19, 2014 at 9:04 AM, Julian Foad <julianf...@btopenworld.com> wrote: > Ben Reser wrote: > >> On 2/18/14, 12:22 PM, Johan Corveleyn wrote: >>> Thanks for the hint. Now, this wasn't an error path (just a commit >>> that should have succeeded and should've written something to stdout). >>> I'm not sure how I can determine that this is the likely cause ... I >>> can't seem to reproduce it, no matter how hard I try :-(. >> >> I unfortunately don't have any good suggestions. However, I'm assuming we >> made >> the change to flush stdout when there wasn't an error for some good reason. > > Just to be clear about the change <http://svn.apache.org/r1543868> and the > reason for it, the change is to flush stdout explicitly before exit rather > than implicitly at exit, and the reason is to consistently report if the > flush fails. From the log message: > > "in order > to report consistently if any information written to standard output is > being lost. > > Standard output would be flushed on exit anyway, but this makes sure that > output is not silently lost if it [the flush] fails. We will get both an > error message > on stderr and a non-zero exit code." > > Previously, in contrast to an error in any other print or flush, if an error > occurred in the final flush (during the C run-time exit) then svn exited > successfully.
Okay, so IIUC, the flush may fail, and before r1543868 we wouldn't detect that (or not in all cases). So a possible hypothesis for the failed test is that the flush somehow failed, and svn didn't notice / report it (by erroring out). With r1543868 this would no longer be possible, because svn would yield an error. Thanks, I guess that makes sense now as a possible cause. -- Johan
