Problems running the regression tests?

[Richard Webb]

I just did a clean run on the trunk regression tests and at the end got a load of warnings such as:

*****Warning - can't open output file: E:/test/results/E:/test/results/boost/bin
.v2/libs/accumulators/test/weighted_tail_variate_means.test/msvc-7.1/debug/itera
tor_debugging-off/link-static/threading-multi/test_log.xml

and the produced results xml file doesnt actually contain any results.
Looks like somethings gone wrong with the results path ("E:/test/results/E:...") ?


Thanks,
Richard Webb

[Richard Webb]

Ping?

Looking at the test results, i see that the steven_watanabe-como and matus_chochlik-msvc runners are missing most of the results. Are they having problems as well?

Richard Webb wrote:

I just did a clean run on the trunk regression tests and at the end got a load of warnings such as:

*****Warning - can't open output file: E:/test/results/E:/test/results/boost/bin
.v2/libs/accumulators/test/weighted_tail_variate_means.test/msvc-7.1/debug/itera
tor_debugging-off/link-static/threading-multi/test_log.xml

and the produced results xml file doesnt actually contain any results.
Looks like somethings gone wrong with the results path ("E:/test/results/E:...") ?

[Rene Rivera-2]

Richard Webb wrote:

> Ping?
>
> Looking at the test results, i see that the steven_watanabe-como and
> matus_chochlik-msvc runners are missing most of the results. Are they having
> problems as well?
>
> Richard Webb wrote:
>> I just did a clean run on the trunk regression tests and at the end got a
>> load of warnings such as:
>>
>> *****Warning - can't open output file:
>> E:/test/results/E:/test/results/boost/bin
>> .v2/libs/accumulators/test/weighted_tail_variate_means.test/msvc-7.1/debug/itera
>> tor_debugging-off/link-static/threading-multi/test_log.xml
>>
>> and the produced results xml file doesnt actually contain any results.
>> Looks like somethings gone wrong with the results path
>> ("E:/test/results/E:...") ?

Anyone? Could this be a result of the recent changes to
process_jam_log.cpp ??

Richard, I would suggest using the Python version of the PJL, but you
are running incremental tests and the Python script doesn't handle
incrementals yet.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Richard Webb]

Rene Rivera-2 wrote:

Anyone? Could this be a result of the recent changes to
process_jam_log.cpp ??

Richard, I would suggest using the Python version of the PJL, but you
are running incremental tests and the Python script doesn't handle
incrementals yet.

I tried running the tests with an older version of process_jam_log.exe (instead of one built by the test scripts) and that seemed to work, so it does seem to be related to some recent changes.

The problem might to be effecting the release branch tests as well - at least, there's a recent BGD-Windows.zip in the release dir on the FTP server which contains an empty xml file.

[Nicola Musatti]

Rene Rivera <grafikrobot <at> gmail.com> writes:

>
> Richard Webb wrote:
> > Ping?
> >
> > Looking at the test results, i see that the steven_watanabe-como and
> > matus_chochlik-msvc runners are missing most of the results. Are they having
> > problems as well?
> >
> > Richard Webb wrote:
> >> I just did a clean run on the trunk regression tests and at the end got a
> >> load of warnings such as:
> >>
> >> *****Warning - can't open output file:
> >> E:/test/results/E:/test/results/boost/bin
> >>

.v2/libs/accumulators/test/weighted_tail_variate_means.test/msvc-7.1/debug/itera
> >> tor_debugging-off/link-static/threading-multi/test_log.xml
> >>
> >> and the produced results xml file doesnt actually contain any results.
> >> Looks like somethings gone wrong with the results path
> >> ("E:/test/results/E:...") ?
>
> Anyone? Could this be a result of the recent changes to
> process_jam_log.cpp ??

Is there a way to look at the process_jam_log command line that causes the
problem? I'll try and perform a regression run to see what is going wrong, but
unfortunately I won't be able to do it before sunday or monday.

Cheers,
Nicola Musatti





_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Richard Webb]

Nicola Musatti <Nicola.Musatti <at> gmail.com> writes:

>
> Is there a way to look at the process_jam_log command line that causes the
> problem? I'll try and perform a regression run to see what is going wrong, but
> unfortunately I won't be able to do it before sunday or monday.
>
> Cheers,
> Nicola Musatti
>

The command line is:

E:\test\boost\status>"E:\test\tools_regression\build\bin\msvc-7.1\release\threading-multi\process_jam_log.exe" "E:\test\results"  0<"E:\test\results\bjam.log"


I had a look at process_jam_log.cpp, and i think the problem might be in the target_directory() function:
The full pjl log contains things like:

line 3244: compile-c-c++ E:\test\results\boost\bin.v2\libs\regex\build\msvc-7.1\debug\threading-multi\c_regex_traits.obj
        line_start: compile-c-c++
        target_directory( "compile-c-c++ E:\test\results\boost\bin.v2\libs\regex\build\msvc-7.1\debug\threading-multi\c_regex_traits.obj") -> "E:/test/results/boost/bin.v2/libs/regex/build/msvc-7.1/debug/threading-multi"
*****Warning - can't open output file: E:/test/results/E:/test/results/boost/bin.v2/libs/array/test/array0.test/msvc-7.1/debug/threading-multi/test_log.xml

One of the recent changes in pjl was to change line 158 from

//
else temp.erase( 0, locate_root.string().size()+1 );
//

to

//
else if ( temp[0] == '/' ) temp.erase( 0, locate_root.string().size()+1 );
//

I tried changing it back, and that seems to have fixed it.

[Rene Rivera-2]

Richard Webb wrote:

> Nicola Musatti <Nicola.Musatti <at> gmail.com> writes:
>
>> Is there a way to look at the process_jam_log command line that causes the
>> problem? I'll try and perform a regression run to see what is going wrong,
>> but
>> unfortunately I won't be able to do it before sunday or monday.
>>
>> Cheers,
>> Nicola Musatti
>>
>
> The command line is:
>
> E:\test\boost\status>"E:\test\tools_regression\build\bin\msvc-7.1\release\threading-multi\process_jam_log.exe"
> "E:\test\results"  0<"E:\test\results\bjam.log"
>
>
> I had a look at process_jam_log.cpp, and i think the problem might be in the
> target_directory() function:
> The full pjl log contains things like:
>
> line 3244: compile-c-c++
> E:\test\results\boost\bin.v2\libs\regex\build\msvc-7.1\debug\threading-multi\c_regex_traits.obj
> line_start: compile-c-c++
> target_directory( "compile-c-c++
> E:\test\results\boost\bin.v2\libs\regex\build\msvc-7.1\debug\threading-multi\c_regex_traits.obj")
> ->
> "E:/test/results/boost/bin.v2/libs/regex/build/msvc-7.1/debug/threading-multi"
> *****Warning - can't open output file:
> E:/test/results/E:/test/results/boost/bin.v2/libs/array/test/array0.test/msvc-7.1/debug/threading-multi/test_log.xml
>
> One of the recent changes in pjl was to change line 158 from
>
> //
> else temp.erase( 0, locate_root.string().size()+1 );
> //
>
> to
>
> //
> else if ( temp[0] == '/' ) temp.erase( 0, locate_root.string().size()+1 );
> //
>
> I tried changing it back, and that seems to have fixed it.

Many, many, thanks for finding that! I've gone ahead and reverted that line.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Beman Dawes]

Rene Rivera wrote:

> Richard Webb wrote:
>> Nicola Musatti <Nicola.Musatti <at> gmail.com> writes:
>>
>>> Is there a way to look at the process_jam_log command line that
>>> causes the
>>> problem? I'll try and perform a regression run to see what is going
>>> wrong,
>>> but
>>> unfortunately I won't be able to do it before sunday or monday.
>>>
>>> Cheers,
>>> Nicola Musatti
>>>
>>
>> The command line is:
>>
>> E:\test\boost\status>"E:\test\tools_regression\build\bin\msvc-7.1\release\threading-multi\process_jam_log.exe"
>>
>> "E:\test\results"  0<"E:\test\results\bjam.log"
>>
>> I had a look at process_jam_log.cpp, and i think the problem might be
>> in the
>> target_directory() function:
>> The full pjl log contains things like:
>>
>> line 3244: compile-c-c++
>> E:\test\results\boost\bin.v2\libs\regex\build\msvc-7.1\debug\threading-multi\c_regex_traits.obj
>>
>>     line_start: compile-c-c++
>>     target_directory( "compile-c-c++
>> E:\test\results\boost\bin.v2\libs\regex\build\msvc-7.1\debug\threading-multi\c_regex_traits.obj")
>>
>> ->
>> "E:/test/results/boost/bin.v2/libs/regex/build/msvc-7.1/debug/threading-multi"
>>
>> *****Warning - can't open output file:
>> E:/test/results/E:/test/results/boost/bin.v2/libs/array/test/array0.test/msvc-7.1/debug/threading-multi/test_log.xml
>>
>>
>> One of the recent changes in pjl was to change line 158 from
>>
>> //
>> else temp.erase( 0, locate_root.string().size()+1 );
>> //
>>
>> to
>>
>> //
>> else if ( temp[0] == '/' ) temp.erase( 0,
>> locate_root.string().size()+1 );
>> //
>>
>> I tried changing it back, and that seems to have fixed it.
>
> Many, many, thanks for finding that! I've gone ahead and reverted that
> line.

Thanks, Rene.

That line was part of a patch from Nicola Musatti. Nicola, what was that
change trying to accomplish?

--Beman

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing

[Nicola Musatti]

Beman Dawes wrote:
> Rene Rivera wrote:
>> Richard Webb wrote:
[...]

>>> else temp.erase( 0, locate_root.string().size()+1 );
>>> //
>>>
>>> to
>>>
>>> //
>>> else if ( temp[0] == '/' ) temp.erase( 0,
>>> locate_root.string().size()+1 );
>>> //
>>>
>>> I tried changing it back, and that seems to have fixed it.
>>
>> Many, many, thanks for finding that! I've gone ahead and reverted that
>> line.
>
> Thanks, Rene.
>
> That line was part of a patch from Nicola Musatti. Nicola, what was that
> change trying to accomplish?

I remember finding myself in a situation where that particular line
removed a path prefix when temp wasn't pointing at a locate_root
subdirectory, which is what caused me to introduce that change. However
I haven't been able to reconstruct the exact test case :-(

Cheers,
Nicola
--
Nicola.Musatti <at> gmail <dot> com
Home: http://nicola.musatti.googlepages.com/home
Blog: http://wthwdik.wordpress.com/

_______________________________________________
Boost-Testing mailing list
Boost-Testing@...
http://lists.boost.org/mailman/listinfo.cgi/boost-testing