Quantcast

[thread]Forever sleeping

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[thread]Forever sleeping

Boost - Dev mailing list
Recent runs of my regression test runner NA-QNX660-x86 leave a lot of
Boost.Thread test executables stuck in nanosleep, waiting for a condition
variable, or both.

Commit 544eda [1] which switched from CLOCK_REALTIME to CLOCK_MONOTONIC
seems suspicious to me. If the returned timespec is ever compared to values
based on the CLOCK_REALTIME epoch, such as system_clock, the results will be
quite undesirable. Are you sure the return values of timespec_now() are only
ever compared to each other and values based on the CLOCK_MONOTONIC epoch?

[1]
https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e

Regards,

Niklas Angare



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :

> Recent runs of my regression test runner NA-QNX660-x86 leave a lot of
> Boost.Thread test executables stuck in nanosleep, waiting for a
> condition variable, or both.
>
> Commit 544eda [1] which switched from CLOCK_REALTIME to
> CLOCK_MONOTONIC seems suspicious to me. If the returned timespec is
> ever compared to values based on the CLOCK_REALTIME epoch, such as
> system_clock, the results will be quite undesirable. Are you sure the
> return values of timespec_now() are only ever compared to each other
> and values based on the CLOCK_MONOTONIC epoch?
>
> [1]
> https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e
>
>
>
>
I'll rollback it and analyze more deeply the change.

I believed that this was the cause of some timming issues.


Thanks for reporting,

Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :
> Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
>> Recent runs of my regression test runner NA-QNX660-x86 leave a lot of
>> Boost.Thread test executables stuck in nanosleep, waiting for a
>> condition variable, or both.
Is for this reason that the regression test are not updated?

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :

> Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
>> Recent runs of my regression test runner NA-QNX660-x86 leave a lot of
>> Boost.Thread test executables stuck in nanosleep, waiting for a
>> condition variable, or both.
>>
>> Commit 544eda [1] which switched from CLOCK_REALTIME to
>> CLOCK_MONOTONIC seems suspicious to me. If the returned timespec is
>> ever compared to values based on the CLOCK_REALTIME epoch, such as
>> system_clock, the results will be quite undesirable. Are you sure the
>> return values of timespec_now() are only ever compared to each other
>> and values based on the CLOCK_MONOTONIC epoch?
>>
>> [1]
>> https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e
>>
>>
>>
>>
> I'll rollback it and analyze more deeply the change.
>
>
Done.

https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1fa3621b

Please, let me know if it works again.

Vicente


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
Le 24/02/2017 à 15:23, Vicente J. Botet Escriba via Boost a écrit :

> Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :
>> Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
>>> Recent runs of my regression test runner NA-QNX660-x86 leave a lot
>>> of Boost.Thread test executables stuck in nanosleep, waiting for a
>>> condition variable, or both.
>>>
>>> Commit 544eda [1] which switched from CLOCK_REALTIME to
>>> CLOCK_MONOTONIC seems suspicious to me. If the returned timespec is
>>> ever compared to values based on the CLOCK_REALTIME epoch, such as
>>> system_clock, the results will be quite undesirable. Are you sure
>>> the return values of timespec_now() are only ever compared to each
>>> other and values based on the CLOCK_MONOTONIC epoch?
>>>
>>> [1]
>>> https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e
>>>
>>>
>>>
>>>
>> I'll rollback it and analyze more deeply the change.
>>
>>
> Done.
>
> https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1fa3621b 
>
>
> Please, let me know if it works again.
After this commit the regression tests continued to be available.
I'm really sorry if my bug was the cause of then been not refreshed.
If it was the case, our test system would need some improvements.

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
Hi Vicente,

Am Montag, 27. Februar 2017, 07:51:28 CET schrieb Vicente J. Botet Escriba via
Boost:
> > https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c
> > 1fa3621b
> >
> >
> > Please, let me know if it works again.
>
> After this commit the regression tests continued to be available.
> I'm really sorry if my bug was the cause of then been not refreshed.
> If it was the case, our test system would need some improvements.

Unfortunately, the tests are red here again. Both the Boost.Thread and my own
tests using Boost.Thread are timing out instead of finishing.

I get ...failed updating 39 targets... on Ubuntu 16.10 with latest clang trunk
and timeout 30 second. Even 3 minutes does not help.

The test matrix is starting to go yellow again, see

http://www.boost.org/development/tests/develop/developer/output/teeks99-02-dc3-5-14-Docker-64on64-boost-bin-v2-libs-thread-test-ex_tennis-test-clang-linux-3-5~c++14-debug-threading-multi.html

as an example.

Yours,

Jürgen
--
* Dipl.-Math. Jürgen Hunold  !
* voice: ++49 4257 300       ! Fährstraße 1
* fax  : ++49 4257 300       ! 31609 Balge/Sebbenhausen
* [hidden email]             ! Germany

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
"Vicente J. Botet Escriba wrote:
> Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :
>> Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
>>> Recent runs of my regression test runner NA-QNX660-x86 leave a lot of
>>> Boost.Thread test executables stuck in nanosleep, waiting for a
>>> condition variable, or both.
...
>>> https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e
>>>
>> I'll rollback it and analyze more deeply the change.
>>
> Done.
>
> https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1fa3621b
>
> Please, let me know if it works again.

The latest run failed with similar symptoms. I noticed you made another
change so I decided to run the Boost.Thread tests manually.

Commit c7348b29 left seven stuck test processes and b2 reported "failed
updating 85 targets".
Commit 9bbf9bed did not leave any stuck test processes and b2 reported
"failed updating 16 targets".

The following test processes got stuck:
test_2741
test_2741_lib
ex_tennis
ex_tennis_lib
ex_xtime
ex_xtime_lib
test_thread_lib

It looks like these test are failing for other test runners as well but I
don't know if it's for the same reason.

I may not be able to help or tend to the runners for the next two weeks.

Regards,

Niklas Angare
 



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
"Vicente J. Botet Escriba wrote:
> Le 24/02/2017 à 15:23, Vicente J. Botet Escriba via Boost a écrit :
>> Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :
>>> Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
>>>> Recent runs of my regression test runner NA-QNX660-x86 leave a lot of
>>>> Boost.Thread test executables stuck in nanosleep, waiting for a
>>>> condition variable, or both.
...

>>>> https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e
>>>>
>>> I'll rollback it and analyze more deeply the change.
>>>
>> Done.
>>
>> https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1fa3621b
>> Please, let me know if it works again.
> After this commit the regression tests continued to be available.
> I'm really sorry if my bug was the cause of then been not refreshed.
> If it was the case, our test system would need some improvements.

The fact that it ruins the entire run might be specific to my setup. But
other runners that are running tests remotely due to cross-compilation may
also have trouble killing hung test processes.

Does the Boost.Thread tests or Boost.Test in general block any signals,
thereby making it harder to stop the processes? I'm running the tests over
ssh but I'm not sure which signals would be sent to the other side when the
client is stopped by Boost.Build. Maybe SIGHUP?

Regards,

Niklas Angare
 



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 28/02/2017 à 10:20, Niklas Angare via Boost a écrit :

> "Vicente J. Botet Escriba wrote:
>> Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :
>>> Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
>>>> Recent runs of my regression test runner NA-QNX660-x86 leave a lot
>>>> of Boost.Thread test executables stuck in nanosleep, waiting for a
>>>> condition variable, or both.
> ...
>>>> https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e 
>>>>
>>>>
>>> I'll rollback it and analyze more deeply the change.
>>>
>> Done.
>>
>> https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1fa3621b 
>>
>>
>> Please, let me know if it works again.
>
> The latest run failed with similar symptoms. I noticed you made
> another change so I decided to run the Boost.Thread tests manually.
>
> Commit c7348b29 left seven stuck test processes and b2 reported
> "failed updating 85 targets".
> Commit 9bbf9bed did not leave any stuck test processes and b2 reported
> "failed updating 16 targets".
>
> The following test processes got stuck:
> test_2741
> test_2741_lib
> ex_tennis
> ex_tennis_lib
> ex_xtime
> ex_xtime_lib
> test_thread_lib
>
> It looks like these test are failing for other test runners as well
> but I don't know if it's for the same reason.
>
> I may not be able to help or tend to the runners for the next two weeks.
I'm taking a look just now.

I've an hint.
https://github.com/boostorg/thread/commit/c7348b29cf8bfa1272645d04784419d37e1e7db5

Must be more restrictive.

             // old behavior was fine for monotonic
-            return do_wait_until(lock,
boost::detail::timespec_plus(timeout, boost::detail::timespec_now()));
+            return do_wait_until(lock,
boost::detail::timespec_plus(timeout,
boost::detail::timespec_now_realtime()));


-#ifdef CLOCK_MONOTONIC
+#if defined CLOCK_MONOTONIC && defined BOOST_THREAD_USEFIXES_TIMESPEC
       if ( ::clock_gettime( CLOCK_MONOTONIC, &ts ) )

I'll commit these changes soon.

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [thread]Forever sleeping

Boost - Dev mailing list
Le 28/02/2017 à 21:50, Vicente J. Botet Escriba via Boost a écrit :

> Le 28/02/2017 à 10:20, Niklas Angare via Boost a écrit :
>> "Vicente J. Botet Escriba wrote:
>>> Le 24/02/2017 à 13:46, Vicente J. Botet Escriba a écrit :
>>>> Le 22/02/2017 à 23:39, Niklas Angare via Boost a écrit :
>>>>> Recent runs of my regression test runner NA-QNX660-x86 leave a lot
>>>>> of Boost.Thread test executables stuck in nanosleep, waiting for a
>>>>> condition variable, or both.
>> ...
>>>>> https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935ad62580e 
>>>>>
>>>>>
>>>> I'll rollback it and analyze more deeply the change.
>>>>
>>> Done.
>>>
>>> https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1fa3621b 
>>>
>>>
>>> Please, let me know if it works again.
>>
>> The latest run failed with similar symptoms. I noticed you made
>> another change so I decided to run the Boost.Thread tests manually.
>>
>> Commit c7348b29 left seven stuck test processes and b2 reported
>> "failed updating 85 targets".
>> Commit 9bbf9bed did not leave any stuck test processes and b2
>> reported "failed updating 16 targets".
>>
>> The following test processes got stuck:
>> test_2741
>> test_2741_lib
>> ex_tennis
>> ex_tennis_lib
>> ex_xtime
>> ex_xtime_lib
>> test_thread_lib
>>
>> It looks like these test are failing for other test runners as well
>> but I don't know if it's for the same reason.
>>
>> I may not be able to help or tend to the runners for the next two weeks.
> I'm taking a look just now.
>
> I've an hint.
> https://github.com/boostorg/thread/commit/c7348b29cf8bfa1272645d04784419d37e1e7db5 
>
>
> Must be more restrictive.
>
>             // old behavior was fine for monotonic
> -            return do_wait_until(lock,
> boost::detail::timespec_plus(timeout, boost::detail::timespec_now()));
> +            return do_wait_until(lock,
> boost::detail::timespec_plus(timeout,
> boost::detail::timespec_now_realtime()));
>
>
> -#ifdef CLOCK_MONOTONIC
> +#if defined CLOCK_MONOTONIC && defined BOOST_THREAD_USEFIXES_TIMESPEC
>       if ( ::clock_gettime( CLOCK_MONOTONIC, &ts ) )
>
> I'll commit these changes soon.
>
Done. I would say this fix the regression.

Vicente



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Loading...