December 2016 - Boost-users - lists.preview.boost.org

boost_regex compiler error
by Chris Padwick 06 Dec '16

06 Dec '16

Hi - I am stuck on a linker error with the boost_regex library. My platform is ubuntu 16.04 LTS, arm64, NVIDIA TX1. I downloaded and built boost 1.62.0 with the following parameters: ./bootstrap.sh --prefix=/usr/local sudo ./b2 -d2 architecture=arm address-model=64 install I compiled a simple program using this command line: g++ main.cpp -I/usr/local/include -L/usr/local/lib -lboost_regex Here is the program: #include <boost/regex.hpp> #include <iostream> using namespace std; int main(int argc, char *argv[]) { static const boost::regex rxInt("[0-9]+"); string word = "foobar"; if(boost::regex_match(word, rxInt)) { cout << "Integer" << endl; } else { cout << "Not integer" << endl; } return 0; } Here are the linker errors: /tmp/ccuOD7Zj.o: In function `bool boost::regex_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >(__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)': main.cpp:(.text._ZN5boost11regex_matchIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEESaINS_9sub_matchISB_EEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEbT_SJ_RNS_13match_resultsISJ_T0_EERKNS_11basic_regexIT1_T2_EENS_15regex_constants12_match_flagsE[_ZN5boost11regex_matchIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEESaINS_9sub_matchISB_EEEcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEEbT_SJ_RNS_13match_resultsISJ_T0_EERKNS_11basic_regexIT1_T2_EENS_15regex_constants12_match_flagsE]+0x58): undefined reference to `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match()' /tmp/ccuOD7Zj.o: In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::perl_matcher(__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >&, boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags, __gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >)': main.cpp:(.text._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEESaINS_9sub_matchISC_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEC2ESC_SC_RNS_13match_resultsISC_SF_EERKNS_11basic_regexIcSJ_EENS_15regex_constants12_match_flagsESC_[_ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEESaINS_9sub_matchISC_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEEC5ESC_SC_RNS_13match_resultsISC_SF_EERKNS_11basic_regexIcSJ_EENS_15regex_constants12_match_flagsESC_]+0xf8): undefined reference to `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)' collect2: error: ld returned 1 exit status Any hints would be appreciated. Should I try to use an earlier version of boost? thank you!

2 2

[test] Really deactivate test
by Florian Lindner 05 Dec '16

05 Dec '16

Hello, I need to conditionally decativate tests and use a custom decorator for that, like that: virtual void apply(bt::test_unit& tu) { [...] if (std::find(_ranks.begin(), _ranks.end(), rank) == _ranks.end()) { std::cout << rank << " Disable, because of rank, test: " << tu.full_name() << std::endl; tu.p_default_status.value = bt::test_unit::RS_DISABLED; return; } } (i'm happy to provide full source code, if anyone is interested) As you can see it's deativated on some MPI ranks only. However, if a user uses -t "testname" it is activated again. Is there a way to really deactivate the test? Or delete it from the test tree? Thanks, Florian

1 0

VS 2017 RC + boost.context
by Michael Steinberg 05 Dec '16

05 Dec '16

Hi there, I'm trying to build boost with VS 2017 RC but run into problems building boost.context. The project jam file somehow triggers to build the "unsupported.cpp", but I'm not proficient enough with the build system to find out how I can circumvent that. I would be very grateful if somebody could help me out with this. Cheers! Michael

2 4

[Boost.Container] Performance of static_vector with default_init_t
by dariomt＠gmail.com 04 Dec '16

04 Dec '16

Hi, I'm constructing a static_vector<double,N>(n, default_init). I was expecting the constructor call to vanish into just setting the start pointer and the size & capacity members (and verifying n<=N). However, the profiler is showing some time spent in the loop inside uninitialized_default_init_alloc_n (boost/container/detail/utilities.hpp:678) For a builtin type and default_init_t, why do we even need to invoke the allocator? Can't we just leave the memory uninitialized? This is with Boost 1.55 and VS2008 Thanks in advance

2 1

[Boost.Signals2] Problem with cleanup when disconnecting from slot.
by Paul Blampspied 03 Dec '16

03 Dec '16

Am I right in thinking that when a signal is connected to a closure created by boost::bind, then the closure should be destructed when the connection is closed ? I am having trouble because I pass a boost::shared_ptr in the closure. The use count does not drop when the signal connection is closed (the signal is connected to a one-shot slot which closes the connection). As a result the shared_ptr never deletes its data causing a memory leak. I have seen a few mentions of bugs in signals2 with respect to object destruction on connection termination. Perhaps I have fallen foul of that. It seems quite a serious bug though considering the general standard of boost. Given that the one-shot slot receives the shared_ptr I am considering a hack to fix the problem - explicitly break into the shared_ptr and decrement the reference count that I believe should be decremented by conn.disconnect(). Is there a better way ?

1 0

Closure not destructed properly when signals2 connection is closed.
by Paul Blampspied 03 Dec '16

03 Dec '16

Am I right in thinking that when a signal is connected to a closure created by boost::bind, then the closure should be destructed when the connection is closed ? I am having trouble because I pass a boost::shared_ptr in the closure. The use count does not drop when the signal connection is closed (the signal is connected to a one-shot slot which closes the connection). As a result the shared_ptr never deletes its data causing a memory leak. I have seen a few mentions of bugs in signals2 with respect to object destruction on connection termination. Perhaps I have fallen foul of that. It seems quite a serious bug though considering the general standard of boost. Given that the one-shot slot receives the shared_ptr I am considering a hack to fix the problem - explicitly break into the shared_ptr and decrement the reference count that I believe should be decremented by conn.disconnect(). Is there a better way ?

1 0

[Log] Random "double free or corruption" in dtor of attribute_value_set
by robin.lorke＠jenoptik.com 01 Dec '16

01 Dec '16

Hi Gentlemen, I have an application that is using Boost.Log. The application is long-term running (days, weeks, maybe months). Currently I am experiencing random crashes in my application that seem related to Boost.Log. I dont't say that is is a bug in Boost.Log, but probably I am doing something wrong. I am using version 1.55.0 but I also tried upgrading to version 1.61.0 but it is still happening there. I am currently able to reproduce the crash by forcing logs at a pace of 3 records per second. Then it takes up to 3 days for the crash to happen. The application is multi-threaded and therefore several threads may be logging at the same time. For that reason I chose "severity_logger_mt". It seems related to the destruction of objects of type attribute_value_set. This is a gdb stacktrace of the crash (gcc O0 build): (gdb) bt #0 0xb6bdbed8 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:66 #1 0xb6bdf960 in __GI_abort () at abort.c:90 #2 0xb6c139fc in __libc_message (do_abort=2, fmt=0xb6cc8c44 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:200 #3 0xb6c1e17c in malloc_printerr (action=3, str=0xb6cc8d80 "double free or corruption (!prev)", ptr=<optimized out>) at malloc.c:4949 #4 0xb6b3fcb8 in boost::log::v2_mt_posix::attribute_value_set::~attribute_value_set() () from /usr/lib/libboost_log.so.1.55.0 #5 0xb6b42688 in boost::log::v2_mt_posix::record_view::public_data::destroy (boost::log::v2_mt_posix::record_view::public_data const*) () from /usr/lib/libboost_log.so.1.55.0 #6 0xb6b44c7c in boost::log::v2_mt_posix::core::push_record_move (boost::log::v2_mt_posix::record&) () from /usr/lib/libboost_log.so.1.55.0 #7 0xb6e66814 in Logger::addLog(Logger::LEVEL, char const*, char const*, int) () from /usr/lib/libtslog.so.1 #8 0x0005ba50 in addLogRusp (iMessageId=2, sMessage=<optimized out>, sProcess=0x8dee8 "Application", eLevel=Logger::LEVEL_INFO) at ../src/RLS-V/Platform/System.inl.h:303 #9 RLS::Application::fnThreadRuspOut (thread=...) at ../src/RLS-V/Application.cpp:1447 #10 0xb6e7aa4c in Thread::startFunction(void*) () from /usr/lib/libtscommon.so.1 #11 0xb6edae38 in start_thread (arg=0xb3eff460) at pthread_create.c:313 #12 0xb6c7c318 in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) This is the global logger initialization (using some custom attributes): BOOST_LOG_GLOBAL_LOGGER_INIT(appLogger, boost::log::sources::severity_logger_mt< robot::log::Severity >) { core::get()->add_global_attribute("TimeStamp", attributes::local_clock()); core::get()->add_global_attribute("ProcessID", AttrProcessId()); core::get()->add_global_attribute("LineCounter", attributes::counter< unsigned int >()); core::get()->add_global_attribute("Process", attributes::current_process_name()); core::get()->add_global_attribute("Scopes", attributes::named_scope ()); core::get()->add_global_attribute("LineID", attributes::counter< unsigned int >(1)); core::get()->add_global_attribute("SimpleTimeStamp", AttrSimpleTime ()); Logger::init(); sources::severity_logger_mt< Severity > lg; return lg; } These are are my macros for logging: //these are needed to convert a macro into a string #define STRINGIFY(x) #x #define TOSTRING(x) STRINGIFY(x) /* NOTE: * __FUNCTION__ is not a macro. It's a char pointer. So we use an empty std::string as basis to concatenate the char* to it */ #define R_LOG_ID(x,y) BOOST_LOG_SEV (robot::log::appLogger::get(), y) << boost::log::add_value("LogID", x) << boost::log::add_value("FLF", ROBOT_FLF) #define R_LOG(x) R_LOG_ID(0, x) #define ROBOT_FLF std::string() + TOSTRING(__FILE__) + ":" + TOSTRING (__LINE__) + " (" + __FUNCTION__ + ")" While "R_LOG_ID" is the only one that is used currently. There are currently three sinks active: syslog, console and a custom sink sending log records via an IPC mechanism (http://www.cs.cmu.edu/~./IPC/) I am currently testing if it will still happen if I deactivate one or more of those sinks. I imagine it will be hard to tell the exact problem from the information above but maybe you guys could point me in the right direction where to dig deeper. I will happily provide any missing information and/or code snippets that could help. Possibly there are well-known common mistakes that can lead to that memory corruption in attribute_value_set? Maybe something like lazy evaluation of log expressions or multi-threading issues? Many thanks in advance for any help! Robin Lorke

2 1