Избегайте утечки в тривиальном использовании Boost Log

Я получаю отчеты об утечках valgrind из приложения на стороне сервера, использующего boostlog, который распространяется с boost 1.56. отчет valgrind:

==8021== 37 088 байт в 1 159 блоках определенно потеряны в записи о потерях 1 613 из 1 642

==8021== по адресу 0x4A05588: memalign (vg_replace_malloc.c:727)

==8021== по 0x3FDA61118F: tls_get_addr_tail (в /lib64/ld-2.12.so)

==8021== по 0x3FDA61165F: __tls_get_addr (в /lib64/ld-2.12.so)

==8021== по 0x3FE6ABBDCB: __cxa_get_globals (в /usr/lib64/libstdc++.so.6.0.13)

==8021== от 0x730C528: boost::log::v2_mt_posix::aux::unhandled_exception_count() (в /opt/sesteksdk/lib/libboost_log.so.1.56.0)

==8021== by 0x5D54D1F: sestek::mrcp::audio::recognition::AsynchronousRecognizer::Notify(sestek::voice::recognition::IRecognizerNotification const*) (record_ostream.hpp:259)

эта утечка исходит из такой простой строки, как:
LOGGER(debug)<< _chanProp->GetId() << " got recognition ended notification from recognizer";

Мы получаем 5 таких утечек только за один короткий тестовый прогон.

мы используем бэкенд текстового файла, с синхронным приемником, включена автоматическая очистка. В основном:

void InitializeFileLog(const std::string & logDir)
    {   
        boost::shared_ptr< logging::core > loggingCore = logging::core::get();


        loggingCore->add_global_attribute("TimeStamp", attrs::local_clock());

        string logPath = logDir + "/gvzmrcpsr_%N.txt";

        boost::shared_ptr< sinks::text_file_backend > backend =
            boost::make_shared< sinks::text_file_backend >(
                // file name pattern
                keywords::file_name = logPath,
                // rotate the file upon reaching 5 MiB size...
                keywords::rotation_size = 5 * 1024 * 1024,
                // ...or at midnight, whichever comes first
                keywords::time_based_rotation = sinks::file::rotation_at_time_point(0, 0, 0)                    
            );

        backend->auto_flush(true);

        // Wrap it into the frontend and register in the core.
        // The backend requires synchronization in the frontend.
        typedef sinks::synchronous_sink< sinks::text_file_backend > sink_t;
        boost::shared_ptr< sink_t > sink = boost::make_shared< sink_t>(backend);

        loggingCore->add_sink(sink);


        sink->flush();
        sink->set_formatter
            (
            expr::stream
            << expr::attr< boost::posix_time::ptime >("TimeStamp")
            << " : [" << expr::attr< sestek::log::LogLevel >("Severity")
            << "] " << expr::smessage
            );

        backend->set_file_collector(sinks::file::make_collector(
            // rotated logs will be moved here
            keywords::target = logDir + "/old_mrcpsr_plugin_logs",
            // oldest log files will be removed if the total size reaches 100 MiB...
            keywords::max_size = 100 * 1024 * 1024,
            // ...or the free space in the target directory comes down to 50 MiB
            keywords::min_free_space = 50 * 1024 * 1024
        ));

        try
        {
            backend->scan_for_files(sinks::file::scan_all);
        }
        catch(std::exception & )
        {
            //LOGGER(sestek::log::fatal) << "exception during scanning : " << e.what();

        }

    }

Система скомпилирована и запущена на Centos 6.6 с использованием devtoolkit2.0. версия gcc 4.8.2.

Так есть ли проблема в нашем использовании журнала повышения? Или действительно ли в журнале повышения есть такая проблема (ы). Я думаю, что наше использование можно считать тривиальным, мы просто запускаем приведенный выше код конфигурации во время запуска.

Примечание. Несмотря на то, что размер одной утечки может быть достаточно небольшим, наше программное обеспечение запускается как служба на сервере, поэтому повторяющиеся утечки такого рода представляют для нас проблему.