On Thu, Aug 2, 2018 at 12:19 AM, Shyam Ranganathan <srangana@xxxxxxxxxx> wrote: > On 07/31/2018 12:41 PM, Atin Mukherjee wrote: >> tests/bugs/core/bug-1432542-mpx-restart-crash.t - Times out even after >> 400 secs. Refer >> https://fstat.gluster.org/failure/209?state=2&start_date=2018-06-30&end_date=2018-07-31&branch=all, >> specifically the latest report >> https://build.gluster.org/job/regression-test-burn-in/4051/consoleText . >> Wasn't timing out as frequently as it was till 12 July. But since 27 >> July, it has timed out twice. Beginning to believe commit >> 9400b6f2c8aa219a493961e0ab9770b7f12e80d2 has added the delay and now 400 >> secs isn't sufficient enough (Mohit?) > > The above test is the one that is causing line coverage to fail as well > (mostly, say 50% of the time). > > I did have this patch up to increase timeouts and also ran a few rounds > of tests, but results are mixed. It passes when run first, and later > errors out in other places (although not timing out). > > See: https://review.gluster.org/#/c/20568/2 for the changes and test run > details. > If I may ask - why are we always exploring the "increase timeout" part of this? I understand that some tests may take longer - but 400s is quite a non-trivial amount of time - what other efficient means are we not able to explore? > The failure of this test in regression-test-burn-in run#4051 is strange > again, it looks like the test completed within stipulated time, but > restarted again post cleanup_func was invoked. > > Digging a little further the manner of cleanup_func and traps used in > this test seem *interesting* and maybe needs a closer look to arrive at > possible issues here. > > @Mohit, request you to take a look at the line coverage failures as > well, as you handle the failures in this test. -- sankarshan mukhopadhyay <https://about.me/sankarshan.mukhopadhyay> _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
