[serialization] Test runners being stopped
I think there is a bug in the serialization library that is breaking out of the test harness and causing window's error handling to kick in (when running on Windows, obviously). Usually when this happens the test runner application eventually (I believe) times out the test and marks it as failed. However, there are an incredible number of failures happening (since late last week) and they are bogging down the entire test run. Most of the runs I have attempted in the last week on windows have failed...the ones that have succeeded have taken ~12hrs up from the normal 3-4hrs. I was able to capture a stack trace of one of these random failures: msvcp140d.dll!00007ff9cfffb968() Unknown msvcp140d.dll!00007ff9cff73005() Unknown
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::_Endwrite() Line 649 C++
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::close() Line 341 C++
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 155 C++
test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t>
::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1068 C++
test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t>
::`vbase destructor'() C++ test_list_ptrs_text_warchive.exe!test_list() Line 65 C++ test_list_ptrs_text_warchive.exe!test_main(int __formal, char * * __formal) Line 176 C++ test_list_ptrs_text_warchive.exe!main(int argc, char * * argv) Line 203 C++ [External Code]
I'd be happy to help get to the bottom of this, if you can give me any more diagnostic steps to take. We need to resolve this ASAP because it is preventing the windows test runners from producing timely results and we have a release coming up. Thanks, Tom
On 10/15/15 6:54 PM, Tom Kent wrote:
I think there is a bug in the serialization library that is breaking out of the test harness and causing window's error handling to kick in (when running on Windows, obviously). Usually when this happens the test runner application eventually (I believe) times out the test and marks it as failed. However, there are an incredible number of failures happening (since late last week) and they are bogging down the entire test run. Most of the runs I have attempted in the last week on windows have failed...the ones that have succeeded have taken ~12hrs up from the normal 3-4hrs.
I was able to capture a stack trace of one of these random failures: msvcp140d.dll!00007ff9cfffb968() Unknown msvcp140d.dll!00007ff9cff73005() Unknown
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::_Endwrite() Line 649 C++
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::close() Line 341 C++
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 155 C++
test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t>
::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1068 C++
test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t>
::`vbase destructor'() C++ test_list_ptrs_text_warchive.exe!test_list() Line 65 C++ test_list_ptrs_text_warchive.exe!test_main(int __formal, char * * __formal) Line 176 C++ test_list_ptrs_text_warchive.exe!main(int argc, char * * argv) Line 203 C++ [External Code]
I'd be happy to help get to the bottom of this, if you can give me any more diagnostic steps to take. We need to resolve this ASAP because it is preventing the windows test runners from producing timely results and we have a release coming up.
I have been making changes in he serialization library recently - fixing bugs. This turns out to be more difficult than first meets the eye. So I'm a little bogged down on this. I did push some changes to develop, things looked OK so I merged to master. I don't know if this is related to the current issue. As soon as I get my current issues resolved, I'll re-pull from master and quadiple check that things work in my environments. Unfortunately(?) that doesn't include windows. Robert Ramey
On Fri, Oct 16, 2015 at 10:15 AM, Robert Ramey <ramey@rrsd.com> wrote:
On 10/15/15 6:54 PM, Tom Kent wrote:
I think there is a bug in the serialization library that is breaking out of the test harness and causing window's error handling to kick in (when running on Windows, obviously). Usually when this happens the test runner application eventually (I believe) times out the test and marks it as failed. However, there are an incredible number of failures happening (since late last week) and they are bogging down the entire test run. Most of the runs I have attempted in the last week on windows have failed...the ones that have succeeded have taken ~12hrs up from the normal 3-4hrs.
I was able to capture a stack trace of one of these random failures: msvcp140d.dll!00007ff9cfffb968() Unknown msvcp140d.dll!00007ff9cff73005() Unknown
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::_Endwrite() Line 649 C++
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::close() Line 341 C++
test_list_ptrs_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t>
::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 155 C++
test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t>
::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1068 C++
test_list_ptrs_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t>
::`vbase destructor'() C++
test_list_ptrs_text_warchive.exe!test_list() Line 65 C++ test_list_ptrs_text_warchive.exe!test_main(int __formal, char * * __formal) Line 176 C++ test_list_ptrs_text_warchive.exe!main(int argc, char * * argv) Line 203 C++ [External Code]
I'd be happy to help get to the bottom of this, if you can give me any more diagnostic steps to take. We need to resolve this ASAP because it is preventing the windows test runners from producing timely results and we have a release coming up.
I have been making changes in he serialization library recently - fixing bugs. This turns out to be more difficult than first meets the eye. So I'm a little bogged down on this. I did push some changes to develop, things looked OK so I merged to master. I don't know if this is related to the current issue.
As soon as I get my current issues resolved, I'll re-pull from master and quadiple check that things work in my environments. Unfortunately(?) that doesn't include windows.
Would it be possible to revert the changes to develop until you have a better handle on them, so that the runners can continue for all the other projects? This would also rule-out the problem actually being a change in some other library, that is just showing up here. Tom
On 10/16/15 9:25 AM, Tom Kent wrote:
On Fri, Oct 16, 2015 at 10:15 AM, Robert Ramey <ramey@rrsd.com> wrote:
Would it be possible to revert the changes to develop until you have a better handle on them, so that the runners can continue for all the other projects?
I'm not sure this would help. Except for one minor change in the examples which shouldn't affect the testing, I believe that develop and master are in sync. Since windows tests on the master are quite old it may be the problem exists on the master but just aren't showing up there (yet). I'm reluctant to starting doing any git jujitzu at this point as I'm trying to get everything hunky dory before next wednesday when a 1.60 cut off is planned.
This would also rule-out the problem actually being a change in some other library, that is just showing up here.
I don't know if this is easy/possible with the Boost Testing setup but when I run here, I can just switch and particular library between branches and run the tests. That is, you might be able to locally just switch the serialization library to master and run the tests. Since this likely will give the same results, you'd actually have to switch the master to the 1.5 release version. Rest assured that, as we speak, I'm trying to get out the last nits on the next version of the serialization library so hopefully the whole question will be moot soon. I also believe that there is a pending issue related to visibility on GCC plaforms but I have to get other stuff fixed before I can look into this one. Thanks for spending time on this. Your work is very helpful and critically important to the success of Boost. Robert Ramey
Tom
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Robert Ramey -
Tom Kent