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/544eda51bdf0c62b2f29dea6fe1cf935ad... Regards, Niklas Angare
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/544eda51bdf0c62b2f29dea6fe1cf935ad...
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
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
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/544eda51bdf0c62b2f29dea6fe1cf935ad...
I'll rollback it and analyze more deeply the change.
Done. https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1f... Please, let me know if it works again. Vicente
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/544eda51bdf0c62b2f29dea6fe1cf935ad...
I'll rollback it and analyze more deeply the change.
Done.
https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1f...
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
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-d... 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 * jhunold@gmx.eu ! Germany
"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/544eda51bdf0c62b2f29dea6fe1cf935ad...
I'll rollback it and analyze more deeply the change.
Done.
https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1f... 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
"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/544eda51bdf0c62b2f29dea6fe1cf935ad...
I'll rollback it and analyze more deeply the change.
Done.
https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1f...
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
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/544eda51bdf0c62b2f29dea6fe1cf935ad...
I'll rollback it and analyze more deeply the change.
Done.
https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1f...
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/c7348b29cf8bfa1272645d04784419d37e... 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
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/544eda51bdf0c62b2f29dea6fe1cf935ad...
I'll rollback it and analyze more deeply the change.
Done.
https://github.com/boostorg/thread/commit/9bbf9bed80836282263ec0bdea0adf5c1f...
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/c7348b29cf8bfa1272645d04784419d37e...
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
participants (3)
-
Jürgen Hunold -
Niklas Angare -
Vicente J. Botet Escriba