Проблема в выпуске RHEL4 с использованием boost 1.36 и C ++ - PullRequest
4 голосов
/ 23 мая 2011

Я борюсь с загадочной проблемой Я вижу только на моем выпуске сборки RHEL4. Некоторые из моих модульных тестов (с использованием каркаса модульных тестов boost 1.36) не выполняются на RHEL4 (gcc 3.4.6) и используют тип сборки выпуска. Я не вижу проблемы с использованием выпуска RHEL5 или отладочных типов сборки (gcc 4.1.2, boost-1.39); и я нет посмотрите это на 32-битной или 64-битной Windows, используя 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 на всех платформах; но, к сожалению, мы в настоящее время на буст-1,36 для RHEL4 и VS2005, и поэтому это может быть еще не практично.

Я также замечаю, что принудительный вывод определенного логгера на консоль в момент, когда тест не пройден, позволяет пройти тест (не очень хорошо, я знаю)! Подозревая, что это может быть связано с тем, что я прокомментировал все выходные данные логгера и запустил valgrind - вот что опубликовано выше. Если вам нужны фрагменты кода функции init_unit_test_suite; Я могу опубликовать это, если это поможет. Любые идеи для решения этой проблемы приветствуются и приветствуются.

05/26/2011 Редактировать:

Вот 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 Ответ

1 голос
/ 18 июня 2011

Эта «ошибка» в valgrind не обязательно является проблемой.Когда системный вызов вызывается в Linux, память часто приходится копировать из пространства пользователя в пространство ядра.При этом он может копировать неинициализированные байты.

То, что он копирует эти байты в пространство ядра, не означает, что ядро ​​действительно будет что-то делать с неинициализированными байтами.То, что делает ядро ​​с байтами, сильно зависит от семантики рассматриваемого системного вызова.

У Valgrind нет простого способа узнать, нормально ли, что некоторые из байтов, переданных в системном вызове, неинициализированы, поэтомувсегда сигнализирует об ошибке.Valgrind подавляет многие из подобных ошибок.

В этом файле вы можете увидеть некоторые подавления по умолчанию от valgrind: / usr / lib / valgrind / default.supp Вы также можете создать собственное подавлениефайлы, если хотите, и используйте их в своем модульном тесте для подавления сообщения об ошибке.Если вы не испытываете никаких реальных проблем в этой системе, то, вероятно, хорошей идеей является их устранение.Смотрите параметры командной строки valgrind.

...