qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Help needed: test-qht-par hangs on Travis


From: Paolo Bonzini
Subject: Re: [Qemu-devel] Help needed: test-qht-par hangs on Travis
Date: Fri, 11 Jan 2019 13:55:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 10/01/19 21:58, Eduardo Habkost wrote:
> On Mon, Dec 10, 2018 at 05:09:42PM -0200, Eduardo Habkost wrote:
>> On Mon, Dec 10, 2018 at 03:34:27PM -0200, Eduardo Habkost wrote:
>>> On Mon, Dec 10, 2018 at 12:07:20PM -0500, Emilio G. Cota wrote:
>>>> On Mon, Dec 10, 2018 at 14:36:01 -0200, Eduardo Habkost wrote:
>>>>> On Sun, Dec 09, 2018 at 05:27:38PM -0500, Emilio G. Cota wrote:
>>>>>> Can you try re-running the test, after applying the appended patch?
>>>>>> (It disables the "resize" thread.)
>>>>>
>>>>> It is running right now, here:
>>>>> https://travis-ci.org/ehabkost/qemu-hacks/jobs/466074591
>>>>>
>>>>>>
>>>>>> Also, does it reliably hang on Travis, or are these hangs
>>>>>> intermittent?
>>>>>
>>>>> It can be reproduced reliably.  qemu.git builds are failing since
>>>>> Thursday:
>>>>> https://travis-ci.org/qemu/qemu/builds
>>>>
>>>> I see the build you launched timed out. Can you try the following
>>>> patch (after discarding the previous one)? Let's see if just by
>>>> disabling the second test we can get the build to move ahead.
>>>
>>> I will try it.  I'm not sure yet if it's the first or the second
>>> test case timing out.  Maybe the "OK\n" we see in the log file is
>>> from another process running in parallel.
>>
>> Yeah, I think the first test case is the one hanging:
>>
>> https://travis-ci.org/ehabkost/qemu-hacks/jobs/466074591#L7741
> 
> Finally found out what's happening:
> 
> https://travis-ci.org/ehabkost/qemu-hacks/builds/478025908
> 
> sleep(1) is being interrupted before 1 second has elapsed, and
> never exits the loop:
> 
>     do {
>         remaining = sleep(duration);
>     } while (remaining);
> 

Great, then the solution is simply to switch to g_usleep!

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]