Activity for shahes

  • shahes shahes posted a comment on discussion Help

    Ok, thank you for the input.

  • shahes shahes posted a comment on discussion Help

    Hi, yes, I agree the library should not terminate but I was wondering if you had a suggestion on the best way to implement the termination. We have tried a callback to std::terminatewith a call to core::flush() and nothing is output to the logs. We have done this with special macro for the fatal severity. We would prefer to not have a special macro. I thought you might have a suggestion on the best way to implement such a feature using features of the library. Thanks

  • shahes shahes posted a comment on discussion Help

    Well, for one thing the program keeps running. :-) We would like FATAL to call abort or terminate after the log message is written and all the log messages are flushed. Unless we missed something, the log library does not do this for you.

  • shahes shahes posted a comment on discussion Help

    Hi, I was wondering if you have any suggestions on how to correctly implement a fatal log message using the multi-threaded severity logger without creating a special macro for the FATAL condition. Thank you.

  • shahes shahes posted a comment on discussion Help

    Thank you. That does solve the issue.

  • shahes shahes posted a comment on discussion Help

    Continuation of thread: https://sourceforge.net/p/boost-log/discussion/710022/thread/555365ac/?limit=25 Compiled boost 1.80 library using gcc: gcc --version gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0 ./bootstrap.sh sudo ./b2 release link=shared cxxflags=-fPIC cflags=-fPIC -a install Modified boost_1_77_0/libs/log/example/advanced_usage/main.cpp to have some threads. See attached file. Compiled with using thread sanitizer: Ubuntu clang version 14.0.6-++20220622053133+f28c006a5895-1~exp1~20220622173215.107...

  • shahes shahes posted a comment on discussion Help

    Sorry about the off topic post, but it did relate to an earlier post about using the wrap_formatter and getting a race condition. I upgraded to 1.80 and still can reproduce the data race using log/example/advanced_usage/main.cpp with some minor modifications described above.

  • shahes shahes posted a comment on discussion Help

    Hi, to show the data race I modified the following example program: boost_1_77_0/libs/log/example/advanced_usage/main.cpp I added the following functions: void f1(int n, src::severity_logger_mt<severity_level>& slg) { for (int i = 0; i < 25; ++i) { BOOST_LOG_SEV(slg, error) << "Thread 1 executing " << i; ++n; std::this_thread::sleep_for(std::chrono::milliseconds(10)); } } void f2(int& n, src::severity_logger_mt<severity_level>& slg) { BOOST_LOG_SCOPED_LOGGER_TAG(slg, "Tag", "Tagged f2 "); for (int...

  • shahes shahes posted a comment on discussion Help

    I'm wondering if we do not have the logger setup correctly to support a multithreaded environment. Logging.hpp: BOOST_LOG_GLOBAL_LOGGER(boostLogger, boost::log::sources::severity_logger_mt<LogSeverity>) Logging.cpp: BOOST_LOG_GLOBAL_LOGGER_INIT(boostLogger, boost::log::sources::severity_logger_mt<LogSeverity>) { using LoggerType = boost::log::sources::severity_logger_mt<LogSeverity>; LoggerType logger; boost::log::add_file_log( keywords::file_name = fileName, keywords::auto_flush = true, keywords::open_mode...

  • shahes shahes posted a comment on discussion Help

    The test is multi-threaded but it does not use any of the BOOST macros in any of the threads except the main thread. AFAIK it is the BOOST macros that are not thread safe. Only calls to BOOST_LOG_SCOPED_LOGGER_TAG and BOOST_LOG_SEV(logger, severity) << msg are made in the threads. It's the call to expr::stream << expr::attr< std::string >("Tag") that causes the data race. I don't see how the code could be destroying the Tag attribute while some place else is updating it. The Tag attribute for this...

  • shahes shahes posted a comment on discussion Help

    Thank you. I missed that post and option 3. I do have a concern about using BOOST_LOG_SCOPED_LOGGER_ATTR. I currently use this for setting a TAG field but get get thread sanitizer data race errors. I'm using "boost::log::sources::severity_logger_mt<>". I do the following in a few different places. BOOST_LOG_SCOPED_LOGGER_TAG(lg, "Tag", "some-tag-message"); I then run a multi-threaded test program using the clang thread sanitizer and get a data race on the Tag output. expr::stream << expr::format_date_time<...

  • shahes shahes posted a comment on discussion Help

    Ok, I thought it was going to be a bad idea. Do you have a suggestion on how to get FILE for every place the logger is called, so it can participate in filtering? For every "BOOST_LOG_SEV(logger, severity) << msg;" statement in the code we need FILE so we can filter on filename and severity. This needs to be the exact location of the log message so scoping variables will not work. This is an ongoing question for the logger that no one seems to have a good solution for. Any help is greatly apprec...

  • shahes shahes posted a comment on discussion Help

    Andrey, can I get your opinion on a post I saw. Is this an OK idea or a bad idea. It's along the lines of this conversation of how to get file information into the log and it needs to be available for filtering records to boost::log::add_value will not work. From post: https://stackoverflow.com/questions/24750218/boost-log-to-print-source-code-file-name-and-line-number // New macro that includes severity, filename and line number #define CUSTOM_LOG(logger, sev) \ BOOST_LOG_STREAM_WITH_PARAMS( \ (logger),...

  • shahes shahes posted a comment on discussion Help

    Hi, is using the expr::wrap_formatter in multi-threaded log (boost::log::sources::severity_logger_mt) thread safe? I am running the clang thread sanitizer (https://clang.llvm.org/docs/ThreadSanitizer.html) and getting many data race conditions reported. Thanks

  • shahes shahes posted a comment on discussion Open Discussion

    What is the proper way to destruct a global logger? We get valgrind errors on program termination. ==330953== 16 bytes in 1 blocks are still reachable in loss record 3 of 6 ==330953== at 0x48468D5: operator new(unsigned long) (vg_replace_malloc.c:422) ==330953== by 0x4EE0923: boost::detail::add_thread_exit_function(boost::detail::thread_exit_function_base*) (in /usr/local/lib/libboost_thread.so.1.77.0) ==330953== by 0x4D80306: boost::log::v2_mt_posix::sources::aux::get_severity_level() (in /usr/local/lib/libboost_log.so.1.77.0)...

  • shahes shahes posted a comment on discussion Help

    Thank you. I was able to get the expr::wrap_formatter to work.

  • shahes shahes posted a comment on discussion Help

    Is it possible to get a working solution posted for this question? I have a similar issue and cannot get the formatter to compile when used as an expression. template<typename CharT> class SuperCustomFormatter : public boost::log::formatter::basic_formatter<CharT> { public: explicit SuperCustomFormatter(boost::log::attribute_name const& name) : name(name) {} void operator()(boost::log::formatting_ostream& strm, boost::log::value_ref< SuperCustomObject > const& value) const { if (value) { format(strm);...

1