Regression test failures on the develop branch
Hi! I've been doing some work on Boost.Range and have been ignoring complete failures from the following machines: teeks99* *jc-bell jasonr-Ubuntu13.04-intel-13.0.1 I'm concerned that the errors have been present for a couple of weeks. We are almost without MSVC coverage on the develop branch. I have taken to going off-process and after cycling the other platforms pushing to master to get coverage of MSVC. Of course I completely understand the difficulties balancing our busy schedules to devote time to Boost. This isn't a complaint. I wondered if there was already a plan to fix these and if there was anything I could do to help. Do we need more machines covering Microsoft compilers and platforms? Should we be approaching companies that use Boost with Microsoft that might be willing to donate some equipment and/or time? I don't think the risk is unacceptable at present since the new branching model means that at this stage of the schedule a hiccup on master can be quickly reverted without a total train wreck. I think we should probably get on top of this before we reach the final phase of the next release. Please let me know if I can help in any way. Regards, Neil Groves
On Sun, Mar 9, 2014 at 6:06 AM, Neil Groves <neil@grovescomputing.com> wrote:
Hi!
I've been doing some work on Boost.Range and have been ignoring complete failures from the following machines:
teeks99* *jc-bell jasonr-Ubuntu13.04-intel-13.0.1
I'm concerned that the errors have been present for a couple of weeks. We are almost without MSVC coverage on the develop branch. I have taken to going off-process and after cycling the other platforms pushing to master to get coverage of MSVC.
Of course I completely understand the difficulties balancing our busy schedules to devote time to Boost. This isn't a complaint. I wondered if there was already a plan to fix these and if there was anything I could do to help.
Do we need more machines covering Microsoft compilers and platforms? Should we be approaching companies that use Boost with Microsoft that might be willing to donate some equipment and/or time?
I don't think the risk is unacceptable at present since the new branching model means that at this stage of the schedule a hiccup on master can be quickly reverted without a total train wreck. I think we should probably get on top of this before we reach the final phase of the next release.
Please let me know if I can help in any way.
Regards, Neil Groves
There were complete failures for the teeks99* machines for a few weeks, but those have been fixed since the start of last week, many of the tests are cycling correctly. It would appear that there is something specific to range that is causing all the range tests to fail? If there is anything specific about the configuration I can look at, let me know and I'll try to check it out tonight. Tom
On 10 Mar 2014, at 12:50, Tom Kent <lists@teeks99.com> wrote:
On Sun, Mar 9, 2014 at 6:06 AM, Neil Groves <neil@grovescomputing.com> wrote:
<snip>
There were complete failures for the teeks99* machines for a few weeks, but those have been fixed since the start of last week, many of the tests are cycling correctly. It would appear that there is something specific to range that is causing all the range tests to fail?
I have merged to master several times to the point where the Boost.Range code is completely in synchronisation. The develop branch fails to run (I think) since it compiles and links, but the master branch will pass. When I look at the fail links I’m getting no useful information about the failure. Is it possibly a major problem with another component on the develop branch? It looks like Boost.Test is completely failing on the develop branch with MSVC and that this is causing a blanket failure of a number of components including Boost.Range.
If there is anything specific about the configuration I can look at, let me know and I'll try to check it out tonight.
Would it be possible to get a log ok a problem, even if that’s be email? Currently I have nothing to work with to fix the issue. I’m happy to debug, but need some input. If you can send me something that would be super.
Tom
Thanks, Neil Groves
On Mon, Mar 10, 2014 at 5:22 PM, Neil Groves <neilgroves@gmail.com> wrote:
On 10 Mar 2014, at 12:50, Tom Kent <lists@teeks99.com> wrote:
On Sun, Mar 9, 2014 at 6:06 AM, Neil Groves <neil@grovescomputing.com> wrote:
<snip>
There were complete failures for the teeks99* machines for a few weeks, but those have been fixed since the start of last week, many of the tests are cycling correctly. It would appear that there is something specific to range that is causing all the range tests to fail?
I have merged to master several times to the point where the Boost.Range code is completely in synchronisation. The develop branch fails to run (I think) since it compiles and links, but the master branch will pass. When I look at the fail links I’m getting no useful information about the failure.
Is it possibly a major problem with another component on the develop branch? It looks like Boost.Test is completely failing on the develop branch with MSVC and that this is causing a blanket failure of a number of components including Boost.Range.
If there is anything specific about the configuration I can look at, let me know and I'll try to check it out tonight.
Would it be possible to get a log ok a problem, even if that’s be email? Currently I have nothing to work with to fix the issue. I’m happy to debug, but need some input. If you can send me something that would be super.
I've just updated my local develop branch and tried to build my tests and got this: compile-c-c++ bin.v2\libs\test\build\msvc-12.0\debug\address-model-64\asynch-exceptions-on\threading-multi\exception_safety.obj exception_safety.cpp D:\src\_SVN\boost\boost/range/iterator_range_core.hpp(423) : error C2872: 'enable_if' : ambiguous symbol could be 'D:\src\_SVN\boost\boost/utility/enable_if.hpp(36) : boost::enable_if' or 'D:\src\_SVN\boost\boost/test/tree/decorator.hpp(184) : boost::unit_test::decorator::enable_if' D:\src\_SVN\boost\boost/lexical_cast.hpp(2082) : see reference to class template instantiation 'boost::iterator_range<const unsigned char *>' being compiled D:\src\_SVN\boost\boost/lexical_cast.hpp(2078) : while compiling class template member function 'bool boost::detail::lexical_converter_impl<Target,src>::try_convert(const Source &,Target &)' with [ Target=unsigned int , Source=src ] D:\src\_SVN\boost\boost/lexical_cast.hpp(2289) : see reference to function template instantiation 'bool boost::detail::lexical_converter_impl<Target,src>::try_convert(const Source &,Target &)' being compiled with [ Target=unsigned int , Source=src ] D:\src\_SVN\boost\boost/lexical_cast.hpp(2289) : see reference to class template instantiation 'boost::detail::lexical_converter_impl<Target,src>' being compiled with [ Target=unsigned int ] D:\src\_SVN\boost\boost/lexical_cast.hpp(2316) : see reference to function template instantiation 'bool boost::conversion::detail::try_lexical_convert<Target,Source>(const Source &,Target &)' being compiled with [ Target=unsigned int , Source=boost::unit_test::basic_cstring<const char> ] D:\src\_SVN\boost\boost/test/impl/exception_safety.ipp(186) : see reference to function template instantiation 'Target boost::lexical_cast<unsigned int,boost::unit_test::basic_cstring<const char>>(const Source &)' being compiled with [ Target=unsigned int , Source=boost::unit_test::basic_cstring<const char> ] D:\src\_SVN\boost\boost/range/iterator_range_core.hpp(434) : error C2872: 'enable_if' : ambiguous symbol could be 'D:\src\_SVN\boost\boost/utility/enable_if.hpp(36) : boost::enable_if' or 'D:\src\_SVN\boost\boost/test/tree/decorator.hpp(184) : boost::unit_test::decorator::enable_if' call "C:\Program Files (x86)\microsoft visual studio 12.0\vc\vcvarsall.bat" x86_amd64 >nul cl /Zm800 -nologo @"bin.v2\libs\test\build\msvc-12.0\debug\address-model-64\asynch-exceptions-on\threading-multi\exception_safety.obj.rsp" It seems like a name clash somewhere in Boost.Test.
On Mon, Mar 10, 2014 at 8:37 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Would it be possible to get a log ok a problem, even if that’s be email? Currently I have nothing to work with to fix the issue. I’m happy to debug, but need some input. If you can send me something that would be super.
I've just updated my local develop branch and tried to build my tests and got this:
compile-c-c++ bin.v2\libs\test\build\msvc-12.0\debug\address-model-64\asynch-exceptions-on\threading-multi\exception_safety.obj exception_safety.cpp D:\src\_SVN\boost\boost/range/iterator_range_core.hpp(423) : error C2872: 'enable_if' : ambiguous symbol could be 'D:\src\_SVN\boost\boost/utility/enable_if.hpp(36) : boost::enable_if' or 'D:\src\_SVN\boost\boost/test/tree/decorator.hpp(184) : boost::unit_test::decorator::enable_if' D:\src\_SVN\boost\boost/lexical_cast.hpp(2082) : see reference to class template instantiation 'boost::iterator_range<const unsigned char *>' being compiled D:\src\_SVN\boost\boost/lexical_cast.hpp(2078) : while compiling class template member function 'bool
[snip]
D:\src\_SVN\boost\boost/test/impl/exception_safety.ipp(186) : see reference to function template instantiation 'Target boost::lexical_cast<unsigned int,boost::unit_test::basic_cstring<const char>>(const Source &)' being compiled with [ Target=unsigned int , Source=boost::unit_test::basic_cstring<const char> ] D:\src\_SVN\boost\boost/range/iterator_range_core.hpp(434) : error C2872: 'enable_if' : ambiguous symbol could be 'D:\src\_SVN\boost\boost/utility/enable_if.hpp(36) : boost::enable_if' or 'D:\src\_SVN\boost\boost/test/tree/decorator.hpp(184) : boost::unit_test::decorator::enable_if'
call "C:\Program Files (x86)\microsoft visual studio 12.0\vc\vcvarsall.bat" x86_amd64 >nul cl /Zm800 -nologo @"bin.v2\libs\test\build\msvc-12.0\debug\address-model-64\asynch-exceptions-on\threading-multi\exception_safety.obj.rsp"
It seems like a name clash somewhere in Boost.Test.
I may be missing something, but I don't quite understand how boost::unit_test::decorator::enable_if could clash with boost::enable_if. I don't find any global using declarations that could bring boost::unit_test::decorator::enable_if into boost::, but maybe I missed it. There is one using directive in exception_safety_tester::exception_safety_tester() though, where lexical_cast it invoked, but it should not affect iterator_range. Maybe there's a compiler problem involved? Anyway, just to compile things on my end I used the attached patch to work around the problem.
On 03/09/2014 07:06 AM, Neil Groves wrote:
Hi!
I've been doing some work on Boost.Range and have been ignoring complete failures from the following machines:
teeks99* *jc-bell jasonr-Ubuntu13.04-intel-13.0.1
On a somewhat-tangential note, I run the jasonr* set of testers and just noticed that they haven't been producing results for 1.5 weeks or so. Looking through the logs, I see this error just after all of the submodules have been fetched: # Executing GIT command: /hd/boosttest_new/boost_root> git submodule "update" "--init" Submodule path 'libs/log': checked out '33e4c386ff739bc4e5a09534753d8cb69157a9a9' Submodule path 'libs/math': checked out '9f8ffee4b7a3f82b1c582735d43522d7d0cde746' Submodule path 'libs/phoenix': checked out 'a788841844e7cb1f71c650030f986e3860808f5d' error: Your local changes to the following files would be overwritten by checkout: doc/ref/while_d_macros.html Please, commit your changes or stash them before you can switch branches. Aborting Unable to checkout '91fb925e1ca752699c2947b3d5562e64a74973f0' in submodule path 'libs/preprocessor' Traceback (most recent call last): File "run.py", line 83, in <module> runner(root) File "/hd/boosttest_new/tools_regression_src/regression.py", line 264, in __init__ self.main() File "/hd/boosttest_new/tools_regression_src/regression.py", line 650, in main getattr(self,action_m)() File "/hd/boosttest_new/tools_regression_src/regression.py", line 588, in command_regression self.command_get_tools() File "/hd/boosttest_new/tools_regression_src/regression.py", line 314, in command_get_tools self.git_branch()) File "/hd/boosttest_new/tools_regression_src/regression.py", line 914, in git_checkout self.git_command( 'submodule', 'update', '--init' ) File "/hd/boosttest_new/tools_regression_src/regression.py", line 899, in git_command raise Exception( 'GIT command "%s" failed with code %d' % (git_cli, rc) ) The regression test script then aborts. Is there some kind of fix that needs to be applied here? Jason
participants (5)
-
Andrey Semashev -
Jason Roehm -
Neil Groves -
Neil Groves -
Tom Kent