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

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

std::future::wait_for() not working in Boost UDP socket async receive operation
by jc.francois＠gmail.com 30 Nov '16

30 Nov '16

The good people over at stackoverflow were not able to help me with this issue that I expected to be trivial. I am writing a UDP server app with Boost that should listen on a socket for 5 seconds and if no datagram has been received within these 5 seconds, move on to do other things. After some research I decided to try the solution based on std::future. The problem is that the call to wait_for() always times out as if no data was received. But if I set a breakpoint on the line that executes after the timeout and that I inspect variables I see that the buffer contains the received datagram and the remote_endpoint object contains the address of the client. In other words the socket receive works as expected but the std::future::wait_for() does not react. why? Here is my test server code: { try { boost::asio::io_service io_service; boost::asio::io_service::work work(io_service); std::thread thread([&io_service]() { io_service.run(); }); udp::socket socket(io_service, udp::endpoint(udp::v4(), 10000)); char recv_buf[8]; for (;;) { ZeroMemory(recv_buf, 8); udp::endpoint remote_endpoint; std::future<std::size_t> recv_length; recv_length = socket.async_receive_from( boost::asio::buffer(recv_buf), remote_endpoint, 0, boost::asio::use_future); if (recv_length.wait_for( std::chrono::seconds(5)) == std::future_status::timeout) { printf("time out. Nothing received.\n"); } else { printf("received something: %s\n", recv_buf); } } io_service.stop(); thread.join(); } catch (std::exception& e) { printf("Error: %s\n", e.what()); } return 0; }

4 5

Question on data structure usage
by Ram 29 Nov '16

29 Nov '16

Hi, I have a map as follows, boost::unordered_map<string, string> sample_map; I would like to look up the keys using wildcards/regex from the user and get the values corresponding to it(get multiple matches). It looked like there is no straightforward way to do it. So, I was thinking as an when I populate the map, I create a seperate data structure to store the keys, so that I can get the values(list) that match my user inputted regex/wildcard search. The I use this list to get the values from the map. What data structure can I use for this purpose? Is my approach correct? Or can I do this directly using the map? Please help me solve this problem. Thanks, -R

4 10

Re: [Boost-users] Do we have plan to support VS 2017?
by senthil vel 29 Nov '16

29 Nov '16

Hi All, I am using VS 2017 for my software development.The last official release of boost ( boost_1_62_0 ) supports VS 2015. When will we get VS 2017 supported boost library? Is there any workaround, till we get the support? Regards, Senthil

2 1

[Boost.DateTime] How to bypass checks in boost::gregorian::date constructor
by dariomt＠gmail.com 28 Nov '16

28 Nov '16

>From the docs I see: "date(greg_year, greg_month, greg_day) Construct from parts of date. Throws bad_year, bad_day_of_month, or bad_day_month (derivatives of std::out_of_range) if the year, month or day are out of range." In my use case, I know for sure that the year, month and date are all in the valid range of values, so all the validity checks done by the library become redundant. Is it possible to somehow bypass those checks?

1 0

Re: [Boost-users] Building Boost 1.62 With Visual Studio 2017 RC
by Trueman, Chris 24 Nov '16

24 Nov '16

1 0

Building Boost 1.62 With Visual Studio 2017 RC
by Trueman, Chris 24 Nov '16

24 Nov '16

2 1

Assertion failure in r_c_shortest_paths.hpp
by Amit Prakash Ambasta 23 Nov '16

23 Nov '16

Hi, I have a sample r_c_shortest_paths use case demonstrated below. However on executing this code, assertion error occurs at /usr/include/boost/graph/r_c_shortest_paths.hpp:473: Assertion `p_cur_label->b_is_valid' failed. I've referred to the prior issue reported at https://svn.boost.org/trac/boost/ticket/11723 However, against his example specified, I can not reproduce the error.

1 0

[release] Boost 1.63.0 Beta 1
by Marshall Clow 21 Nov '16

21 Nov '16

The first beta packages for 1.63.0 beta 1 are now available: <https://sourceforge.net/projects/boost/files/boost/1.63.0.beta.1/> The SHA256 checksums are as follows: 3dbc1bca10941710755c13a00b1ae56d2d37fe90bbadcf9746203194f9d33e3a boost_1_63_0.7z c8b986fd57e436fd88dbc70e51d3e21efa2be3bdf835fa499b2cf6c0a8cc2985 boost_1_63_0.tar.bz2 745d99e4be9c0f324ec7ba15b7d228fd780067f2e8aeae2f16660a4cf6e6a051 boost_1_63_0.tar.gz e66bd6e2f637148c314398b92bc1f3cbdc777ee282f9de7885697afad3d9c202 boost_1_63_0.zip As always, the release managers would appreciate it if you download the archive of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

3 4