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

boost build 1.45 filesystem v3 broken
by Avi Bahra 25 Nov '10

25 Nov '10

Boost 1.45 does not build on AIX using the latest compiler. v11.1 Error's of the following are shown: vacpp.compile.c++ tmpBuildDir/boost/bin.v2/libs/filesystem/build/vacpp/debug/link-static/threading-multi/v3/src/operations.o "./boost/filesystem/v3/path.hpp", line 482.7: 1540-0716 (S) The template argument "boost::iterator" does not match the template parameter "class Derived". It appears that this has been broken for quite a while. At least since boost 1.44 Are the authors of file system aware of this issue and are there any plans to get this fixed ? Does any one know of any work around ? Any help appreciated. Best regards, Ta, Avi

1 0

Error when calling boost::asio::async_read on a boost::asio::serial_port
by Whitham Reeve 25 Nov '10

25 Nov '10

Hello all, I am having trouble getting asio serial ports to work. Specifically when I call boost::asio::async_read, it immediately calls the read completion handler with error EINVAL aka Invalid argument. Please help! I have invested significant time in asio serial ports! Mac OSX 10.6.4 GCC 4.2.1 boost version 1.44.0 The test case console output: $ ./test ERROR 22 Invalid argument $ The test case code: #include <iostream> #include <cstdlib> #include <vector> #include <boost/asio.hpp> #include <boost/bind.hpp> const int HeaderSize = 2; std::vector<char> ReadVector; void ReadHandler(const boost::system::error_code& error, std::size_t bytes_transferred) { if (error) { std::cout << "ERROR " << error.value() << " " << error.category().message( error.value()) << std::endl; return; } else { std::cout << "Bytes Received" << std::endl; } } int main () { ReadVector.resize(2000); boost::asio::io_service SerialService; boost::asio::serial_port SerialPort(SerialService, "/dev/tty.usbserial-FTCW1RJN"); boost::asio::serial_port_base::baud_rate baud_option(115200); SerialPort.set_option(baud_option); assert(SerialPort.is_open()); boost::asio::async_read(SerialPort, boost::asio::buffer(ReadVector, HeaderSize), boost::bind(&ReadHandler, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); SerialService.run(); } -- Whitham D. Reeve II 907-764-5263

1 0

[spirit] qi::raw and skip parsers
by Juraj Ivančić 25 Nov '10

25 Nov '10

Hi. I got unexpected results when I introduced qi::raw[] inside qi expressions. It seems that under certain circumstances qi::raw[] inhibits skip parser and thus fails to parse valid input. Furthermore, parse error only occurs if expression is stored in a rule - if expression is used directly as an argument to qi::parse everything works. Example attached. Is this a bug? If not - could someone kindly explain the rationale for this behavior. Best Regards, Juraj Ivančić

2 2

thread lock-guard race condition
by Kraus Philipp 25 Nov '10

25 Nov '10

Hello, I have written this little example: boost::mutex mutex; void thread() { for (int i = 0; i < 5; ++i) { boost::this_thread::sleep(boost::posix_time::seconds(3)); boost::lock_guard<boost::mutex> lock(mutex); std::cout << "Thread " << boost::this_thread::get_id() << ": " << i << std::endl; } } int main(int argc, char *argv[]) { boost::thread t1(thread); boost::thread t2(thread); t1.join(); t2.join(); } I compile the code with pthread option on the gcc (4.0.1). In the first case the program works, but if I use the helgrind tool of valgrind I'll get this errors (sorry for the long messages). I would like to understand what I have done wrong. I hope I understand the lock_guard in the correct way: If I create the lock with the mutex variable the thread, that creates the lock runs down the next lines. All other threads that run into the lock_guard line blocks until the lock variable of the first thread call the destructor (which should be on every loop iteration). Thanks for help Phil ------Valgrind Logs----------- ==19846== Thread #1 is the program's root thread ==19846== Thread #3 & #2 was created ==19846== at 0x15A1FDE: __bsdthread_create (in /usr/lib/ libSystem.B.dylib) ==19846== by 0x378F4: pthread_create_WRK (hg_intercepts.c:257) ==19846== by 0x379C8: pthread_create (hg_intercepts.c:294) ==19846== by 0x55C06: boost::thread::start_thread() (in libboost_thread.dylib) ==19846== by 0x9FED: boost::thread::thread<void (*)()>(void (*)(), boost::disable_if<boost::is_convertible<void (*&)(), boost::detail::thread_move_t<void (*)()> >, boost::thread::dummy*>::type) (in ./main) ==19846== by 0x2A82: main (in ./main) This message is show for thread #1, #2 and #3 ==19846== Possible data race during read of size 4 at 0x5e008 by thread #3 ==19846== at 0x56381: void boost::call_once<void (*) ()>(boost::once_flag&, void (*)()) (in libboost_thread.dylib) ==19846== by 0x545AC: thread_proxy (in libboost_thread.dylib) ==19846== by 0x37828: mythread_wrapper (hg_intercepts.c:221) ==19846== by 0x15A2154: _pthread_start (in /usr/lib/ libSystem.B.dylib) ==19846== by 0x15A2011: thread_start (in /usr/lib/libSystem.B.dylib) ==19846== This conflicts with a previous write of size 4 by thread #2 ==19846== at 0x5647F: void boost::call_once<void (*) ()>(boost::once_flag&, void (*)()) (in /libboost_thread.dylib) ==19846== by 0x545AC: thread_proxy (in /libboost_thread.dylib) ==19846== by 0x37828: mythread_wrapper (hg_intercepts.c:221) ==19846== by 0x15A2154: _pthread_start (in /usr/lib/ libSystem.B.dylib) ==19846== by 0x15A2011: thread_start (in /usr/lib/libSystem.B.dylib) ==19846== Thread #2: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion ==19846== at 0x385D2: pthread_cond_timedwait_WRK (hg_intercepts.c: 764) ==19846== by 0x386B0: pthread_cond_timedwait$* (hg_intercepts.c:798) ==19846== by 0x5AABB: boost ::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, boost::posix_time::ptime const&) (in libboost_thread.dylib) ==19846== by 0x54DC5: boost::this_thread::sleep(boost::posix_time::ptime const&) (in libboost_thread.dylib) ==19846== by 0xEE31: void boost ::this_thread ::sleep<boost::posix_time::seconds>(boost::posix_time::seconds const&) (in ./main) ==19846== by 0x23F8: thread() (in ./main) ==19846== by 0x545CC: thread_proxy (in libboost_thread.dylib) ==19846== by 0x37828: mythread_wrapper (hg_intercepts.c:221) ==19846== by 0x15A2154: _pthread_start (in /usr/lib/ libSystem.B.dylib) ==19846== by 0x15A2011: thread_start (in /usr/lib/libSystem.B.dylib) The next message is shown for the thread #2 & #3 ==19846== Thread #3: lock order "0x2500668 before 0x25005C8" violated ==19846== at 0x37E1B: pthread_mutex_lock (hg_intercepts.c:496) ==19846== by 0x5ABA3: boost ::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, boost::posix_time::ptime const&) (in libboost_thread.dylib) ==19846== by 0x54DC5: boost::this_thread::sleep(boost::posix_time::ptime const&) (in libboost_thread.dylib) ==19846== by 0xEE31: void boost ::this_thread ::sleep<boost::posix_time::seconds>(boost::posix_time::seconds const&) (in ./main) ==19846== by 0x23F8: thread() (in ./main) ==19846== by 0x545CC: thread_proxy (in libboost_thread.dylib) ==19846== by 0x37828: mythread_wrapper (hg_intercepts.c:221) ==19846== by 0x15A2154: _pthread_start (in /usr/lib/ libSystem.B.dylib) ==19846== by 0x15A2011: thread_start (in /usr/lib/libSystem.B.dylib) ==19846== Required order was established by acquisition of lock at 0x2500668 ==19846== at 0x37E1B: pthread_mutex_lock (hg_intercepts.c:496) ==19846== by 0x15A3452: _pthread_cond_wait (in /usr/lib/ libSystem.B.dylib) ==19846== by 0x15C89F7: pthread_cond_timedwait$UNIX2003 (in /usr/ lib/libSystem.B.dylib) ==19846== by 0x38575: pthread_cond_timedwait_WRK (hg_intercepts.c: 760) ==19846== by 0x386B0: pthread_cond_timedwait$* (hg_intercepts.c:798) ==19846== by 0x5AABB: boost ::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, boost::posix_time::ptime const&) (in libboost_thread.dylib) ==19846== by 0x54DC5: boost::this_thread::sleep(boost::posix_time::ptime const&) (in libboost_thread.dylib) ==19846== by 0xEE31: void boost ::this_thread ::sleep<boost::posix_time::seconds>(boost::posix_time::seconds const&) (in ./main) ==19846== by 0x23F8: thread() (in ./main) ==19846== by 0x545CC: thread_proxy (in libboost_thread.dylib) ==19846== by 0x37828: mythread_wrapper (hg_intercepts.c:221) ==19846== by 0x15A2154: _pthread_start (in /usr/lib/ libSystem.B.dylib) ==19846== followed by a later acquisition of lock at 0x25005C8 ==19846== at 0x37E1B: pthread_mutex_lock (hg_intercepts.c:496) ==19846== by 0x53E6A: boost::this_thread::interruption_point() (in libboost_thread.dylib) ==19846== by 0x5AAC2: boost ::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, boost::posix_time::ptime const&) (in /libboost_thread.dylib) ==19846== by 0x54DC5: boost::this_thread::sleep(boost::posix_time::ptime const&) (in libboost_thread.dylib) ==19846== by 0xEE31: void boost ::this_thread ::sleep<boost::posix_time::seconds>(boost::posix_time::seconds const&) (in ./main) ==19846== by 0x23F8: thread() (in ./main) ==19846== by 0x545CC: thread_proxy (in libboost_thread.dylib) ==19846== by 0x37828: mythread_wrapper (hg_intercepts.c:221) ==19846== by 0x15A2154: _pthread_start (in /usr/lib/ libSystem.B.dylib) ==19846== by 0x15A2011: thread_start (in /usr/lib/libSystem.B.dylib)

3 3

filesystem::current_path() memory leak?
by clarkm2 25 Nov '10

25 Nov '10

After a few hour searching for a memory leak, the cause seems to be related to the following line: boost::filesystem::path full_path( boost::filesystem2::current_path() ); or boost::filesystem2::current_path(); I'm loading the boost filesystem library as a dynamically linked library ( boost_filesystem-vc100-mt-gd-1_44.dll ) in a MFC application using VC++ 2010. I'm calling the current_path function during the application's InitInstance method. I'm a little clueless about the cause of the memory leak, so any suggestions would be helpful. I doubt the the memory dump will be useful, but here it is: Detected memory leaks! Dumping objects -> {285} normal block at 0x00036578, 80 bytes long. Data: <ABCDEFGHIJKLMNOP> 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 {284} normal block at 0x00035278, 8 bytes long. Data: < ![ > EC FD 21 5B 00 00 00 00 {283} normal block at 0x00036418, 48 bytes long. Data: < > 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 {282} normal block at 0x00035CB8, 8 bytes long. Data: < ![ > 0C FE 21 5B 00 00 00 00 {281} normal block at 0x00035C70, 8 bytes long. Data: < ![ > CC FD 21 5B 00 00 00 00 {159} normal block at 0x00035798, 8 bytes long. Data: < ![ > AC FD 21 5B 00 00 00 00 {158} normal block at 0x00035708, 80 bytes long. Data: <ABCDEFGHIJKLMNOP> 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 {157} normal block at 0x000356C0, 8 bytes long. Data: < ![ > 18 FD 21 5B 00 00 00 00 {156} normal block at 0x00035650, 48 bytes long. Data: < > 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 {155} normal block at 0x00035608, 8 bytes long. Data: <8 ![ > 38 FD 21 5B 00 00 00 00 Object dump complete. -- View this message in context: http://boost.2283326.n4.nabble.com/filesystem-current-path-memory-leak-tp30… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[Spirit]Kleene star with arguments having optional attributes.
by Paul Graphov 25 Nov '10

25 Nov '10

Hello Boost Users, I'm now building configuration file parser with Boost.Spirit. I have a little trouble understanding how this parser builds attribute: It was supposed to parse strings throwing 'p' letter away. *((qi::char_ - 'p') | qi::lit('p')) attribute of qi::lit is Unused. attribute of (qi::char_ - 'p') is char. so attribute of ((qi::char_ - 'p') | qi::lit('p')) should be optional<char> that is uninitialized optional value when matched against character 'p' After applying Kleene star it should became vector<optional<char> >. It seems to be compatible with string (at least it compiles). But 'p' letters are not thrown away. The full example is here: http://pastebin.com/tCMw22Zy The output of that example is: Full parsing Result: "abcpppdef" Is it possible to make such a parser without using semantic actions like [bind(&string::append, res, _1)] or something like that, which seem to be less elegant solution. Thanks!

3 6

questions about recursing a directory tree
by Zsolt Ero 25 Nov '10

25 Nov '10

I am just learning C++ and for a first project I would like to write a program which goes recursively through a directory tree and returns the newest and the oldest file date. I have been following the documentation, but I couldn't really find a working example for a recursive algorithm. Shell I start by using this code from the v2 documentation? ---------------------------------- bool find_file( const path & dir_path, // in this directory, const std::string & file_name, // search for this name, path & path_found ) // placing path here if found { if ( !exists( dir_path ) ) return false; directory_iterator end_itr; // default construction yields past-the-end for ( directory_iterator itr( dir_path ); itr != end_itr; ++itr ) { if ( is_directory(itr->status()) ) { if ( find_file( itr->path(), file_name, path_found ) ) return true; } else if ( itr->path().filename() == file_name ) // see below { path_found = itr->path(); return true; } } return false; } ------------------------------- The other way I figured out is with recursive_directory_iterator: ------------------------------ #include "boost/filesystem.hpp" #include <iostream> namespace fs = boost::filesystem; fs::recursive_directory_iterator end; fs::recursive_directory_iterator dir("e:\\docs"); void main() { for ( ; dir != end; ++dir ) { std::cout << *dir << std::endl; } } ------------------------------- Is it safe to use recursive_directory_iterator on a really big directory tree? I mean is it going to copy the whole tree into memory? Does it walk through the whole directory tree the moment it's called, or it only accesses the disk on a ++ operation one-by-one? I still haven't looked into how to compare two files' date, but could you give a hint about which function shell I use? Is it possible to use just a simple < or > operation on file dates, or I need to write manually if year1 > year2 and if month1 > month2, etc? Thanks in advance, Zsolt

1 2

asio UDP async receive question - how to do this properly?
by Ákos Maróy 25 Nov '10

25 Nov '10

Hi, I wonder what the proper pattern is to receive messages, store them, and process them in an async manner? What I'm trying to do, and which doesn't work: - receive the packets in an async call - copy the data over - start to receive again after copying - store the data using a producer - consumer pattern, using a mutex - process the data in another thread (which is the consumer in the pattern) but, this doesn't seem to work, as a lot of packets are lost. my assumption is that because the handler function blocks on the mutex, and returns 'late', packets received in the meantime are lost forever. but: how to do this properly? I have a small sample here: http://pastebin.com/NnbK1T7G , which is based on one of the asio examples. the sample code is quite simple: - it allows sync sending of messages (strings) - it allows async reception of such messages - it will put each received message into a vector, which is guarded by a mutex - another thread will process messages from this vector on a regular basis, which processing is also guarded by a mutex. if I compile & run the sample, I get: ./async_asio b sent 20000 messages a received 1981 messages which is a profound loss of packets. as seen in the sample, after the receive handler is called, the recieved message is copied over, and socket::async_receive_from() is called ASAP. I don't see what else would need to be done to have all messages received. If I remove the processing of messages in threa_func(), the results are markedly better: ./async_asio b sent 20000 messages a received 19963 messages increasing the sleeping time at the end does no good - it seems the messages were lost already. Akos

2 4

A question about boost thread
by x57978 25 Nov '10

25 Nov '10

Hi, Does somebody know whether the boost thread can set the affinity like other thread? Thanks. Hongmiao

1 0

[asio] strange behaviour on android
by Igor R 24 Nov '10

24 Nov '10

Hello, Recently I ported my application to Android, and after some testing I encountered the following strange behavior. Long story short: I send text to a peer and sometimes it gets "cut" in the beginning. like this: aaa\r\nbbb\r\nccc\r\nddd\r\n becomes \nccc\r\nddd\r\n I checked with sniffer, and ensured that the problem is really in my application. To send the text I use the following simple approach: * io_service::run is always invoked from one thread * the data comes from another thread and gets posted to the io_service thread: void connection::send(const std::string &str) { io_.post(boost::bind(&connection::doSend, shared_from_this(), str)); } * then it's streamed into asio::streambuf: void connection::doSend(const std::string &str) { std::ostream(&output_).write(str.c_str(), str.length()); } * and finally async_write is invoked, IF it's not in progress: if (!activeWrite_) { activeWrite_ = true; async_write(m_output, boost::bind(&connection::sent, shared_from_this(), asio::placeholders::error)); } (of course, in sent() handler async_write is re-activated, if needed). I understand that I add data to the streambuf, while async_write is in progress, but it's done in the same thread, and seems to be legitimate. The above approach works on Windows and on some other platforms, it was stress-tested, and never showed any problem. OTOH, on Android the above issue happens very frequently (~20% of events). The only difference here is that I compiled my project with BOOST_ASIO_DISABLE_FENCED_BLOCK, because otherwise the linker complains it doesn't see definitions of some gcc synchronization intrinsics. Is it possible that this's the problem? As far as I see, fenced_block is used when a completion handler is called, so I can't see how it can be connected to my problem... Anyway, I'd appreciate any idea. Thanks.

1 1