RE: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On February 14, 2019 17:34, Max Kirillov wrote:
> To: Randall S. Becker <rsbecker@xxxxxxxxxxxxx>
> Cc: 'Johannes Schindelin via GitGitGadget' <gitgitgadget@xxxxxxxxx>;
> git@xxxxxxxxxxxxxxx; 'Junio C Hamano' <gitster@xxxxxxxxx>; 'Max Kirillov'
> <max@xxxxxxxxxx>
> Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
> 
> On Thu, Feb 14, 2019 at 05:17:26PM -0500, Randall S. Becker wrote:
> > Unfortunately, subtest 13 still hangs on NonStop, even with this
> > patch, so our Pipeline still hangs. I'm glad it's better on Azure, but
> > I don't think this actually addresses the root cause of the hang. This
> > is now the fourth attempt at fixing this. Is it possible this is not
> > the test that is failing, but actually the git-http-backend? The code
> > is not in a loop, if that helps. It is not consuming any significant
> > cycles. I don't know that part of the code at all, sadly. The code is
> > here:
> >
> > * in the operating system from here up *
> >   cleanup_children + 0x5D0 (UCr)
> 
> ... so does the process which the stack was taken from has any children
> processes still?
> 
> I could imagine if a child somehow manages to end up in uninterruptible
> sleep, then probably it would never complete this way, wouldn't it?

Yes, this is typical of a hang. Two processes reading on the same pipe, or
one reading on a pipe and the other waiting for something that never shows.
Or one process attempting both reading and writing on the same pipe (no
kernel threads here). I did not see anything actually in sleep. perl is in a
close call, waiting for its output to be consumed - which never happens,
making me suspect this is a pipe setup issue, but I can't demonstrate that,
sorry.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux