On Wed, Feb 19, 2014 at 9:04 AM, Julian Foad <julianfoad_at_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
Received on 2014-02-19 09:20:07 CET