On 8/28/2019 12:15 PM, SZEDER Gábor wrote:
> On Wed, Aug 28, 2019 at 11:39:44AM -0400, Jeff King wrote:
>> On Wed, Aug 28, 2019 at 10:54:12AM -0400, Jeff King wrote:
>>
>>>> Unfortunately, however, while running './t5516-fetch-push.sh -r 1,79
>>>> --stress' to try to reproduce a failure caused by those mingled
>>>> messages, the same check only failed for a different reason so far
>>>> (both on Linux and macOS (on Travis CI)):
>>>
>>> There's some hand-waving argument that this should be race-free in
>>> 014ade7484 (upload-pack: send ERR packet for non-tip objects,
>>> 2019-04-13), but I am not too surprised if there is a flaw in that
>>> logic.
>>
>> By the way, I've not been able to reproduce this locally after ~10
>> minutes of running "./t5516-fetch-push.sh -r 1,79 --stress" on my Linux
>> box. I wonder what's different.
>>
>> Are you running the tip of master?
>
> Yeah, but this seems to be one of those "you have to be really lucky,
> even with --stress" cases.
>
> So... I was away for keyboard for over an hour and let it run on
> 'master', but it didn't fail. Then I figured that I give it a try
> with Derrick's patch, because, well, why not, and then I got this
> broken pipe error in ~150 repetitions. Run it again, same error after
> ~200 reps. However, I didn't understand how that patch could lead to
> broken pipe, so went back to stressing master... nothing. So I
> started writing the reply to that patch saying that it seems to cause
> some racy failures on Linux, and was already proofreading before
> sending when the damn thing finally did fail. Oh, well.
>
> Then tried it on macOS, and it failed fairly quickly. For lack of
> better options I used Travis CI's debug shell to access a mac VM, and
> could reproduce the failure both with and without the patch before it
> timeouted.
I'm running these tests under --stress now, but not seeing the error
you saw.
However, I do have a theory: the process exits before flushing the
packet line. Adding this line before exit(1) should fix it:
packet_writer_flush(writer);
I can send this in a v2, but it would be nice if you could test this
in your environment that already demonstrated the failure.
Thanks,
-Stolee
