setting FIXTURES_* and RESOURCE_LOCK caused permission denied for dependent test?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

setting FIXTURES_* and RESOURCE_LOCK caused permission denied for dependent test?

Quang Ha
Hi all,

I am facing the issue of FIXTURES for setting up dependent test. Using RESOURCE_LOCK. Currently, it looks something like this:

===================================================
set_test_properties(run_simulation PROPERTIES FIXTURES_SETUP ${simulation_name})
set_test_properties(compare_results PROPERTIES FIXTURES_REQUIRED ${simulation_name})

[...]

set_test_properties(run_simulation compare_results PROPERTIES RESOURCE_LOCK data_${simulation_name})
===================================================

If I include the line of RESOURCE_LOCK, the compare_results test will failed with permission denied. Removing it will make it run fine. I don't think I'm doing anything wrong though - why such behaviour is observed?

Thanks,
QT

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: setting FIXTURES_* and RESOURCE_LOCK caused permission denied for dependent test?

Craig Scott-3


On Fri, Aug 3, 2018 at 12:56 PM, Quang Ha <[hidden email]> wrote:
Hi all,

I am facing the issue of FIXTURES for setting up dependent test. Using RESOURCE_LOCK. Currently, it looks something like this:

===================================================
set_test_properties(run_simulation PROPERTIES FIXTURES_SETUP ${simulation_name})
set_test_properties(compare_results PROPERTIES FIXTURES_REQUIRED ${simulation_name})

[...]

set_test_properties(run_simulation compare_results PROPERTIES RESOURCE_LOCK data_${simulation_name})
===================================================

If I include the line of RESOURCE_LOCK, the compare_results test will failed with permission denied. Removing it will make it run fine. I don't think I'm doing anything wrong though - why such behaviour is observed?

There doesn't seem to be anything wrong with your example code above, but the problem might be in the other things that you have omitted. Does anything else use the same resource lock name? If so, those are most likely the cause. The code above on its own should not be able to lead to the behavior you have described, since the use of RESOURCE_LOCK only has the effect of preventing tests with the same named resource from running concurrently. It doesn't touch any files directly, only your tests themselves would be doing that. The other thing I would check is the specific reason why the compare_results test is complaining with the message "permission denied". Maybe add more debug logging to the test case to check what you expect to exist (or not exist) at the start of the test. You can also make ctest show more output by adding the -V option which will show all the commands and test output.

--
Craig Scott
Melbourne, Australia


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake