关于使用Boost 1.36和C ++发行的RHEL4的问题
|
我正在努力解决一个神秘的问题
我只在我的RHEL4版本中看到。我的某些单元测试(使用boost 1.36单元测试框架)在RHEL4(gcc 3.4.6)上并使用release build-type失败。使用RHEL5版本或调试版本类型(gcc 4.1.2,boost-1.39)时,我看不到问题;我也不
请在Windows 32位或64位(使用Visual Studio 2005(使用boost-1.36)或2008(使用boost-1.39))上看到它。
怀疑这可能是由于一些细微的内存问题所致,我着手在测试应用程序上运行valgrind(保留问题的最小情况)。这是我使用“完全无法访问”模式运行valgrind时得到的结果:
==12285== Memcheck, a memory error detector.
==12285== Copyright (C) 2002-2005, and GNU GPL\'d, by Julian Seward et al.
==12285== Using LibVEX rev 1575, a library for dynamic binary translation.
==12285== Copyright (C) 2004-2005, and GNU GPL\'d, by OpenWorks LLP.
==12285== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==12285== Copyright (C) 2000-2005, and GNU GPL\'d, by Julian Seward et al.
==12285== For more details, rerun with: -v
==12285==
==12285== My PID = 12285, parent PID = 12284. Prog and args are:
==12285== ./myprojd
==12285==
==12285== Syscall param sigaltstack(ss) points to uninitialised byte(s)
==12285== at 0x3AD682EDA9: sigaltstack (in /lib64/tls/libc-2.3.4.so)
==12285== by 0x6488638: boost::detail::signal_handler::~signal_handler()
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x648975E: boost::execution_monitor::catch_signals
(boost::unit_test::callback0<int> const&)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x6489813: boost::execution_monitor::execute
(boost::unit_test::callback0<int> const&)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x648F2E4: boost::unit_test::framework::run(unsigned long, bool)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x649BD02: boost::unit_test::unit_test_main(bool (*)(), int, char**)
(in /<path_to>/libboost_unit_test_framework-gcc34-mt-1_36.so.1.36.0)
==12285== by 0x4147F0: main (init.cpp:132)
==12285== Address 0x7FEFFF3B0 is on thread 1\'s stack
==12285==
==12285== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 4 from 1)
==12285== malloc/free: in use at exit: 190,112 bytes in 1,869 blocks.
==12285== malloc/free: 23,128 allocs, 21,259 frees, 2,520,845 bytes allocated.
==12285== For counts of detected errors, rerun with: -v
==12285== searching for pointers to 1,869 not-freed blocks.
==12285== checked 2,184,272 bytes.
==12285==
==12285== LEAK SUMMARY:
==12285== definitely lost: 0 bytes in 0 blocks.
==12285== possibly lost: 0 bytes in 0 blocks.
==12285== still reachable: 190,112 bytes in 1,869 blocks.
==12285== suppressed: 0 bytes in 0 blocks.
==12285== Reachable blocks (those to which a pointer was found) are not shown.
==12285== To see them, rerun with: --show-reachable=yes
当然,我是在调试模式下运行的(尽管正如我提到的,错误仅在发布模式下发生)。如果我在发布模式下运行valgrind,我会得到相同的输出(也许
较少的细节(如行号)。由此看来,问题可能出在boost-1.36,或者我对init_unit_test_suite的定义?显然,我可以尝试的一件事是
在所有平台上使用boost-1.39运行;但不幸的是,我们目前在RHEL4和VS2005上使用boost-1.36,因此这可能还不可行。
我还观察到,在测试失败的点强制将某些记录程序输出控制台,使测试能够通过(不好,我知道)!怀疑这可能是由于我注释了所有记录器的输出并运行valgrind所致-这就是上面发布的内容。如果您需要一些init_unit_test_suite函数的代码段;如果有帮助,我可以发布。任何解决此问题的想法都值得欢迎和赞赏。
2011年5月26日修改:
这是init_unit_test_suite-如果有人可以看看,不胜感激。
std::ofstream log_stream;
std::ofstream report_stream;
const_string retrieve_framework_parameter( const_string cla_name, int argc, char** argv ) {
//- first try to find parameter among command line arguments if present
if( argc ) {
//- locate corresponding cla name
if( !cla_name.is_empty() ) {
for( int i = 1; i < argc; ++i ) {
if( cla_name == const_string( argv[i], cla_name.size() ) && argv[i][cla_name.size()] == \'=\' ) {
const_string result = argv[i] + cla_name.size() + 1;
for( int j = i; j < argc; ++j ) {
argv[j] = argv[j+1];
}
--argc;
return result;
}
}
}
}
return std::getenv( cla_name.begin() );
}
//! Format results to CPP UNIT xml
class simple_report_formatter : public results_reporter::format {
public:
virtual void results_report_start( std::ostream&) {
}
virtual void results_report_finish( std::ostream&) {
}
virtual void test_unit_report_start(test_unit const&, std::ostream&) {
}
virtual void test_unit_report_finish(test_unit const& tu, std::ostream& out) {
if( tu.p_type == tut_case ) {
const test_results& r = results_collector.results(tu.p_id);
if( r.passed() ) {
out<<\"[PASS] \";
} else {
out<<\"[FAIL] \";
}
out<<\"Test Case <unit_\"<<tu.p_name.get()<<\"> \";
if( !r.passed() ) {
out<<\" - \";
out<<\"!! Assertions failed: \"<<r.p_assertions_failed;
out<<\" - See log files for details on failures !!\";
}
out<<std::endl;
#if defined(MYPROJ_WINDOWS) && defined(MYPROJ_DEBUG)
if( !r.passed() ) {
std::ostringstream msg;
msg<<\"!! \"<<tu.p_name.get()<<\" FAILED !!\"<<std::endl;
OutputDebugStringA(msg.str().c_str());
}
#endif
}
}
virtual void do_confirmation_report(test_unit const&, std::ostream&) {
}
};
bool init_unit_test_suite() {
const_string log_file = retrieve_framework_parameter(
\"--log_file\",
framework::master_test_suite().argc,
framework::master_test_suite().argv
);
if( !log_file.empty() ) {
log_stream.open(log_file.begin());
unit_test_log.set_stream(log_stream);
}
const_string report_file = retrieve_framework_parameter(
\"--report_file\",
framework::master_test_suite().argc,
framework::master_test_suite().argv
);
if( !report_file.empty() ) {
report_stream.open(report_file.begin());
results_reporter::set_stream(report_stream);
}
if( runtime_config::report_format() == CLF ) {
results_reporter::set_format(new simple_report_formatter);
}
// This is providing the sensible default configuration when the test is being run
// without any input parameters whatsoever: print the final report to console
if( framework::master_test_suite().argc <= 1 ) {
results_reporter::set_stream(std::cout);
results_reporter::set_format(new simple_report_formatter);
results_reporter::set_level(DETAILED_REPORT);
}
framework::master_test_suite().p_name.set(MYPROJ_TEST_SUITE_NAME);
return true;
}
没有找到相关结果
已邀请:
1 个回复
倾坞髓