September 2010 - Boost - lists.preview.boost.org

[thread] Memory leak in Boost.Thread?
by Denis Arnaud 03 Oct '10

03 Oct '10

Hello, a Fedora user has reported a potential memory leak in Boost.Thread (see https://bugzilla.redhat.com/show_bug.cgi?id=627875 for details), detected with Valgrind in (at least) versions 1.41.0 and 1.44.0. Following is a code snippet allowing to reproduce the issue: ==================================== #include <boost/thread.hpp> void someWork() { double a; for(int i= 0;i< 1000;i++) { a+=log((double)i); } } int main() { for(int i = 0; i< 10; ++i) { boost::thread_group pool; for(int j = 0; j< 100; ++j) { pool.create_thread(someWork); } pool.join_all(); } } ==================================== Then, following is Valgrind's report: ==================================== ==6442== Memcheck, a memory error detector ==6442== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==6442== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==6442== Command: ./boost_leak ==6442== ==6442== ==6442== HEAP SUMMARY: ==6442== in use at exit: 8 bytes in 1 blocks ==6442== total heap usage: 5,967 allocs, 5,966 frees, 701,720 bytes allocated ==6442== ==6442== 8 bytes in 1 blocks are still reachable in loss record 1 of 1 ==6442== at 0x4C2615D: malloc (vg_replace_malloc.c:195) ==6442== by 0x4E3F989: boost::detail::get_once_per_thread_epoch() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39923: ??? (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E39BC8: boost::detail::get_current_thread_data() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A528: boost::this_thread::interruption_enabled() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x4E3A548: boost::this_thread::disable_interruption::disable_interruption() (in /usr/lib64/libboost_thread-mt.so.1.44.0) ==6442== by 0x404DC4: boost::shared_mutex::lock() (in /tmp/boost_leak) ==6442== by 0x40588D: boost::lock_guard<boost::shared_mutex>::lock_guard(boost::shared_mutex&) (in /tmp/boost_leak) ==6442== by 0x405DB5: boost::thread* boost::thread_group::create_thread<void (*)()>(void (*)()) (in /tmp/boost_leak) ==6442== by 0x403B91: main (in /tmp/boost_leak) ==6442== ==6442== LEAK SUMMARY: ==6442== definitely lost: 0 bytes in 0 blocks ==6442== indirectly lost: 0 bytes in 0 blocks ==6442== possibly lost: 0 bytes in 0 blocks ==6442== still reachable: 8 bytes in 1 blocks ==6442== suppressed: 0 bytes in 0 blocks ==6442== ==6442== For counts of detected and suppressed errors, rerun with: -v ==6442== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6) ==================================== Is that really a memory leak? Kind Regards Denis

3 5

[filesystem] Issue with replace_extension
by cheesy4poofs 02 Oct '10

02 Oct '10

I've recently switched all our code to filesystem v3 and added BOOST_FILESYSTEM_NO_DEPRECATE on our builds for good measure. One of the changes I had to fix was our use of change_extension(), which was modified to use the replace_extension() method. However, some of our code started failing and I tracked it down to this example: boost::filesystem::path p("C:\\database\\test\\filename"); p.replace_extension(".db"); std::cout << p.string() << std::endl; // OUTPUT - C:\database\test\filename.db p = "C:\\database.1\\test\\filename"; p.replace_extension(".db"); // bug? std::cout << p.string() << std::endl; // OUTPUT - C:\database.db As you can see, in the second example, it truncates the path and assumes the directory name "database.1" has the extension that needs replacing. change_extension() did not behave this way. Is this the expected behavior? Thanks, Scott

2 1

[1.43.0] [variant] Compilation errors when swapping variant type objects
by Adam Badura 01 Oct '10

01 Oct '10

We are using Boost 1.43.0 (we tried to move to 1.44.0 but there were some problems which I reported some time ago) in Visual Studio 2010. And there are some compilation problems when variant type objects are swapped. This does not affect all variant types but I didn't figured out what are the exact conditions (however I guess it is likely something with namespaces and templates). Following code demonstrates the issue: ---------------------------------------- #include <cstdlib> #include <list> #include <boost/variant.hpp> int main() { typedef boost::variant< std::list< int >::iterator > variant_type; variant_type v; variant_type().swap( v ); return EXIT_SUCCESS; } ---------------------------------------- compilation fails with following message: ---------------------------------------- 1>d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(155): error C2668: 'boost::detail::variant::detail::move_swap::swap' : ambiguous call to overloaded function 1> d:\libraries\boost_1_43_0\boost\variant\detail\move.hpp(141): could be 'void boost::detail::variant::detail::move_swap::swap<T>(T &,T &)' 1> with 1> [ 1> T=T0 1> ] 1> c:\program files\microsoft visual studio 10.0\vc\include\utility(100): or 'void std::swap<T>(_Ty &,_Ty &)' [found using argument-dependent lookup] 1> with 1> [ 1> T=T0, 1> _Ty=T0 1> ] 1> while trying to match the argument list '(T0, T0)' 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(698) : see reference to function template instantiation 'void boost::detail::variant::move_swap<T>(T &,T &)' being compiled 1> with 1> [ 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(825) : see reference to function template instantiation 'void boost::detail::variant::swap_with<Variant>::operator ()<T>(T &) const' being compiled 1> with 1> [ 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(141) : see reference to function template instantiation 'void boost::detail::variant::invoke_visitor<Visitor>::internal_visit<T>(T &,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(169) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke_impl<Visitor,VoidPtrCV,T>(int,Visitor &,VoidPtrCV,T *,boost::mpl::false_)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\detail\visitation_impl.hpp(252) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl_invoke<Visitor,VoidPtrCV,T0,NoBackupFlag>(int,Visitor &,VoidPtrCV,T *,NoBackupFlag,int)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> T=T0 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1769) : see reference to function template instantiation 'void boost::detail::variant::visitation_impl<first_which,first_step,Visitor,VoidPtrCV,boost::variant<T0_>::has_fallback_type_>(const int,const int,Visitor &,VoidPtrCV,boost::mpl::false_,NoBackupFlag,Which *,step0 *)' being compiled 1> with 1> [ 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void *, 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> NoBackupFlag=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>::has_fallback_type_, 1> Which=first_which, 1> step0=first_step 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1780) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor_impl<Visitor,void*>(int,int,Visitor &,VoidPtrCV)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::invoke_visitor<boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>>>, 1> VoidPtrCV=void * 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1803) : see reference to function template instantiation 'void boost::variant<T0_>::internal_apply_visitor<boost::detail::variant::invoke_visitor<Visitor>>(boost::detail::variant::invoke_visitor<Visitor> &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1637) : see reference to function template instantiation 'void boost::variant<T0_>::apply_visitor<boost::detail::variant::swap_with<Variant>>(Visitor &)' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>>, 1> Variant=boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>, 1> Visitor=boost::detail::variant::swap_with<boost::variant<std::_List_iterator<std::_List_val<int,std::allocator<int>>>>> 1> ] 1> d:\libraries\boost_1_43_0\boost\variant\variant.hpp(1631) : while compiling class template member function 'void boost::variant<T0_>::swap(boost::variant<T0_> &)' 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] 1> d:\test\simple\simple.cpp(10) : see reference to class template instantiation 'boost::variant<T0_>' being compiled 1> with 1> [ 1> T0_=std::_List_iterator<std::_List_val<int,std::allocator<int>>> 1> ] ---------------------------------------- Adam Badura

2 2

Potential scoped_ptr improvement
by David Abrahams 30 Sep '10

30 Sep '10

The incantation scoped_ptr<Base> x( new Derived ); will succeed and produce undefined behavior upon x's destruction unless Derived has a trivial or virtual d'tor. It would be pretty easy to prevent something like that from compiling when has_virtual_destructor<Base>::value is false. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

[btree] Library working with more compilers and standard libraries
by Beman Dawes 30 Sep '10

30 Sep '10

* VC++ 10 and MinGW/gcc 4.5 are my primary platforms, and the tests continue to pass on those. Some of the tests have been beefed up, too. * The Btree library now passes tests with Cygwin/gcc 4.3. That was a bug in my POSIX implementation code that is now fixed. * VC++ 9 is working OK in release mode. There is a bug in some debug mode code in the standard library <algorithm> header's lower_bound and upper_bound functions. I'm not sure how to deal with that. Maybe supply lower_bound/upper_bound implementations, and switch to them when needed. * I'm about to start a round of tests on Linux. --Beman

3 4

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 29 Sep '10

29 Sep '10

> > > Well, I believe I got it wrong. It is concept maps where the specializtion > > > is to tke plce. It should read: > > > > > > explicit concept< typename T > IntOrPair > "explicit concepts" were never part of any accepted proposal ;-) > > { > > int sum_ints_impl( T const& ); > > } > > > > concept_map IntOrPair<int> > > { > > int sum_ints_impl( int const& i ) { return i; } > > } > > > > template< IntOrPair type1, IntOrPair type2 > > > concept_map IntOrPair< std::pair<type1, type2> > > > { > > int sum_ints_impl( std::pair<First, Second> const& p ) { > > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > > } > > } > > > > template<IntOrPair T> > > int sum_ints( T const & t ) > > { > > return IntOrPair::sum_ints_impl( t ); > > } > I think what you wrote is equivalent to what I posted in > http://permalink.gmane.org/gmane.comp.lib.boost.devel/209012 > However, as I noted in that message, trying to constrain something to > be either an Int or a Pair is really against the spirit of GP. I understand. On the other hand, even though concepts were designed to support GP, once they are designed it would be interesting to see how they can be used to do other thing, and what other possibilities they enable. Regards, &rzej

2 1

Advice sought on memory allocation latency reduction C++ standard proposal
by Niall Douglas 29 Sep '10

29 Sep '10

Dear Boost Devs, I am hoping to gain feedback on an ISO C++ standard library proposal I hope to submit. It consists of a rationale (http://mallocv2.wordpress.com/) which shows how growth in RAM capacity is exponentially outgrowing the growth in RAM access speed. The consequences are profound: computer software which has always been written under the assumption of scarcity of RAM capacity will need to be retargeted to assume the scarcity of RAM access speed instead. I appreciate that Boost is not the C++ standard library, however I have asked this on comp.std.c++ and received no reply at all. The proposal comes in two parts: (i) The C proposal (http://mallocv2.wordpress.com/the-c-proposal-text/) which extends the classic 1979 malloc API to enable realloc() to speculatively attempt in-place allocation resizing and (ii) the C++ proposal (http://mallocv2.wordpress.com/the-cpp-proposal-text/) which extends std::allocator<> with batch allocation and deallocation member functions along with a reallocate() member function. These work much as expected and are intended for STL implementations - I have given a sample std::vector<>::reserve() implementation for the Dinkumware STL which attempts an in-place extension before performing a move construction of the vector contents. I am going to guess that these member functions will be fairly uncontroversial - reallocate() in particular has been in the SGI STL for a while, though in an unhelpful form which is basically a realloc() wrapper. What I think will likely be much more controversial are the new std namespace functions: template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer New(Args&&... args); template<class T, class allocator=allocator<T>, class... Args> typename allocator<T>::pointer NewA(size_t n, Args&&... args); template<class T, class allocator=allocator<T> > void Delete(typename allocator<T>::const_pointer p); template<class T, class allocator=allocator<T> > void DeleteA(typename allocator<T>::const_pointer p); These parallel global operators new and delete except of course that they are standard functions and take a std::allocator<> type with which they perform the allocation and deallocation. The biggest danger here obviously enough is the chance of collision with any New() or Delete() defined by application code as the overloading and type specialisation problems (thanks to the unhelpful syntax) of operators new and delete are well known. The second biggest danger is the perhaps confusing duplication of functionality, though of course std::New() and std::Delete() are intended as a superset of global operators new and delete. I would appreciate any feedback, and in case you don't think discussion of this topic is appropriate here I will cross post this email to comp.std.c++. You can reply there instead if you wish. My thanks in advance for your time and consideration. Niall Douglas -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.

3 2

Floating point truncation bug in qi::float_
by Henry Tan 29 Sep '10

29 Sep '10

Hi I am using boost 1.4.1 Spirit::Qi. I think we have a floating point truncation bug in the qi::float_ parser. I attached a simple program to repro the bug. Below are some examples of an input floating point gets truncated (=>) by the qi::float_: 12312321421421 => 12312321720320.000000 123123214 => 123123216.000000 123233.4124 => 123233.406250 I don't see the same issue with the qi::double_. Wondering if this is a known issue? Regards, HTan

5 4

How to cast _1 ?
by Henry Tan 29 Sep '10

29 Sep '10

I want to cast a value of _1 to a _val of a different type. How do I do that? I tried using static_cast_, it does not compile for me. rule<UInt8Iterator, UInt32()> MyRule; ... MyRule = (long_ | float_) [_val = static_cast_<UInt32>(_1)] Any help is appreciated Regards, Henry

2 1

Re: [boost] [asio] Question regarding io_service.post() and pool of threads
by Tan, Tom (Shanghai) 29 Sep '10

29 Sep '10

-----Original Message----- Date: Tue, 28 Sep 2010 11:18:22 +0800 From: Romain CHANU <romainchanu(a)gmail.com> To: boost(a)lists.boost.org Subject: [boost] [asio] Question regarding io_service.post() and pool of threads > >Extracted from Boost Asio reference: "The >io_service<http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/ref >erence/io_service.html> >guarantees >that the handler will only be called in a thread in which the run(), >run_one (), poll() or poll_one() member functions is currently being invoked." > >For my understanding, since there is a pool of threads, a handler can >run concurrently in different threads, even though we are using >io_service.post(). > >Is that correct? My concern here is about the need or not to lock the >data accessed by the handler. > My understanding is that, it's another way to say that those calls won't create an additional thread while calling the completion handler having been registered by io_service.post(). Therefore, if io_service.run() itself is running in n threads, it's guaranteed all the registered completion handler will be invoked in at most n threads at random order, since there are only n threads in total . -Tom

2 1