- Boost-users - lists.boost.org

[pool] singleton_pool crash in multithreaded mode
by Phil Bouchard 07 May '11

07 May '11

Hi, I have a strange bug here. I am using singleton_pool and it crashes at a call to singleton_pool::ordered_malloc in multithreaded mode. The funny thing is I am locking a mutex before the call and it still crashes. The test file can be found here: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/th… And the calls to the pool (allocate & deallocate) a made from class "pool" of the following file: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/detail/block_base.h… The backtrace I get is: #0 0x0000000000407842 in boost::simple_segregated_storage<unsigned long>::try_malloc_n (start=@0x42e7ddc0, n=10, partition_size=8) at /home/vnmr1/phil/boost_1_46_1/boost/pool/simple_segregated_storage.hpp:236 #1 0x00000000004078f7 in boost::simple_segregated_storage<unsigned long>::malloc_n (this=0x614d88, n=11, partition_size=8) at /home/vnmr1/phil/boost_1_46_1/boost/pool/simple_segregated_storage.hpp:260 #2 0x000000000040c2ab in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x614d88, n=88) at /home/vnmr1/phil/boost_1_46_1/boost/pool/pool.hpp:527 #3 0x000000000040c9b8 in boost::singleton_pool<boost::detail::sh::pool, 1u, boost::default_user_allocator_new_delete, boost::details::pool::pthread_mutex, 32u, 0u>::ordered_malloc (n=88) at /home/vnmr1/phil/boost_1_46_1/boost/pool/singleton_pool.hpp:72 #4 0x000000000040d937 in boost::detail::sh::pool::allocate (s=88) at ../../../boost/detail/block_base.hpp:150 #5 0x000000000040d9cd in boost::detail::sh::block<std::pair<int, int> >::operator new (s=88) at ../../../boost/detail/block_base.hpp:301 #6 0x000000000040d9f1 in boost::detail::sh::make_block<std::pair<int, int>, std::pair<int, int> > (t0=@0x42e7e030) at ../../../boost/block_ptr.hpp:492 #7 0x0000000000405fd3 in worker (id=1) at thread_test.cpp:17 #8 0x0000000000408b5c in boost::_bi::list1<boost::_bi::value<int> >::operator()<void (*)(int), boost::_bi::list0> (this=0x1776e660, f=@0x1776e658, a=@0x42e7e0cf) at /home/vnmr1/phil/boost_1_46_1/boost/bind/bind.hpp:253 #9 0x0000000000408b9a in boost::_bi::bind_t<void, void (*)(int), boost::_bi::list1<boost::_bi::value<int> > >::operator() (this=0x1776e658) at /home/vnmr1/phil/boost_1_46_1/boost/bind/bind_template.hpp:20 #10 0x0000000000408bb8 in boost::detail::thread_data<boost::_bi::bind_t<void, void (*)(int), boost::_bi::list1<boost::_bi::value<int> > > >::run ( this=0x1776e4d0) at /home/vnmr1/phil/boost_1_46_1/boost/thread/detail/thread.hpp:61 #11 0x00002b6910e0a914 in thread_proxy () from /home/vnmr1/phil/lib/libboost_thread.so.1.46.1 #12 0x0000003906a06367 in start_thread () from /lib64/libpthread.so.0 #13 0x0000003905ed30ad in clone () from /lib64/libc.so.6 Anybody has any idea? Thanks, -Phil

1 0

Re: [Boost-users] [iostreams] Flushing problems with :filtering_ostream
by eg 06 May '11

06 May '11

On Wed, May 4, 2011 at 2:31 PM, Bo Jensen <jensen.bo(a)gmail.com> wrote: > > > In the interest of closure, can you confirm (from the comment you made in > > another thread), that this now works for you after changing the stream > open > > call to be: > > > > std::ofstream strm("test.gz", std::ios_base::out | > std::ios_base::binary); > > > > I know that it works for me when I tried it. > > > Thanks for your interest in this, much appreciated. The problem > persists, the written file can not be decompressed, I have worked my > way around the problem, so it's not a issue for me anymore, but I > would be happy to help track it down. I think it's very strange you > can run without problems. > > To clarify, when I built and ran it with VS 2008 and boost 1.35 it worked. When I just re-tried using VS 2008 and boost 1.45 or boost 1.46.1, it seems to produce invalid .gz files. Perhaps you can create a New Ticket and enter this as a bug at: https://svn.boost.org/trac/boost/newticket

1 0

Re: [Boost-users] Boost-users Digest, Vol 2714, Issue 3
by bill comment 06 May '11

06 May '11

> > 2719 ?The file handle supplied is not valid?. > > FWIW, this usually means that the socket is already closed. > yes. by the time my connection::do_writeMessage() is called, socket_.is_open() returs false. but, why has it been closed and what the correct way to keep it open? i attempt to keep it open after writing the 1st response as follows: in connection::handle_writeResponse() call start(), which calls socket_.async_read_some() this is similar to the chat client sample. apparently that's not sufficient to keep the socket open for when i want to write to it again. fwiw, TcpView (from SysInternals) shows the socket's state as "established" after the 1st successful write and after the failed 2nd attempt. ???

1 0

MPI with threads - adress not mapped problem
by Kraus Philipp 06 May '11

06 May '11

Hello. I'm using Boost 1.46.0 with OpenMPI 1.5.3 under Gentoo x64. I have compiled OpenMPI with thread and mpithread option and Boost with MPI support. A little testprogram with: #include <boost/mpi.hpp> namespace mpi = boost::mpi; int main(int argc, char* argv[]) { mpi::environment loMPIenv(argc, argv); mpi::communicator loMPICom; return 0; } crashes alway if I run it with "mpiexec -np" (without mpiexec it runs). Sometimes the program hangs or creates the message "adress not mapped" with "Segmentation fault". I have recompiled OpenMPI without threads and mpithreads and it seems, that the errors are gone. Is this a problem with OpenMPI or Boost MPI? Phil

2 3

[boost] [xint] Formal Review Result
by Vladimir Prus 06 May '11

06 May '11

I apologize for the delay in producing the final summary and result of the Boost.Xint review, but here it is. Votes ===== YES: - Christian Henning - Steven Watanabe - Jarrad Waterloo - Edward Diener - Paul A. Bristow NO : - Mathias Gaunard - Joel Falcou - Anders Dalvander - Joachim Faulhaber - Phil Endecott - Domagoj Saric - Gordon Woodhull ("fraction of a vote") I might have missed somebody inside the 454 messages I have as result of the review, but the overall picture is clear -- the votes are split. High-level issues ================= - The claim that the library is "fast" is not necessary true. Phil has did some checking against hand-written assembler that don't look too good. - It is not clear whether the design allows for improving performance of fixed-size integers using specialization (again, see Phil's comments) - There were concerns about COW. In particular, it was very clearly stated that if COW is used, it should work fine in multi-threaded programs. - It was suggested to use ET. - Some folks suggested better separation between algorithms and data representation. Specific issues =============== - It was pointed out that "a + b + c" creates a pile of temporaries, and this can be improved without using ET. - Joachim's review raised a lot of valid points. Section 3 of his reviews in something that should be addressed, more or less entirely. Note that while we normally don't force specific coding style, some of formatting pointed out is simply unacceptable if this code is to be read by anybody. - 'Secure' flag is probably not so much of it. Future directions ================= I think that reviews by Phil and Joachim are most important in specying evolutionary directions for Boost.XInt. Chad made several comments about what he plans to do, in particular: - http://article.gmane.org/gmane.comp.lib.boost.devel/216935 Conclusion ========== I think there's no doubt that (i) this domain is important and (ii) Chad has put a lot of work into this library, producing several iterations. It was pointed out that we have many arbitrary-precision libraries skeletons all around Boost, and providing such a solid offering for review is a significant accomplishment. And it everybody learned a lot during the review. There was a couple of important meta-points raised during review -- whether review should focus on external interface only, and what is the scope of the library. Some reviewers argued that only external interface matters. However, it seems to me (as review manager), that concerns about internal design are valid, and may not be rejected offhand. After all, external interface of an integer library is more or less defined by mathematics, and internal design plays a key role in successfull evolution of the library. There was also heated discussion about the scope of the library, in particular support for fixed-width integers. I think that it's abstractly OK for this library to treat fixed-width integers as second-class citizens. However, I am having hard time determining the intended scope of the library. If I'm doing cryptography, would I really want to implement cryptography algorithms from the books with Boost.XInt, only to introduce bugs that are probably fixed in existing implementations (often, included in the OS). And if I'm really intent on doing that, I probably want raw performance, including a way to plug in optimized backends using SSE 2011, CUDA, and whatever fancy technology is there. If I'm doing general programming, then I'm most likely interested in not too big integers. They might be fixed-width 128-bit integers, or they might be something larger-than-64, but not necessary fixed. However, such integers are not the scope of the library, and they were found to have suboptimal performance. It is certainly possible to refine/define the scope, optimize everything for that scope, accomodate the proposals made during review, and obtain an excellent Boost library. However, there are some many suggestions, and so many planned redesigns and changes, that we need a second look at the library. Further, because of the global nature of the changes, it would be very hard to identify a specific subset that must be improved and then go through mini-review. For that reason, I've arrived at the the following result: Boost.Xint library is not accepted at this time. We'll be happy to have another full review of the library when the next version is ready. Thanks to Chad for the submission and for everybody who participated in the review! - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[Phoenix] Can we use boost::phoenix::function<Impl const&>?
by TONGARI 06 May '11

06 May '11

Greetings, The intuitive way to make a PFO having state is letting boost::phoenix::function hold the impl's reference, however, the following does not work. struct Impl { ...defines a functor having state... }; Impl impl; boost::phoenix::function<Impl const&> f(impl); f(...lazy call...); // should return an actor here, but not compiles Is this intended behavior?

1 0

Syntax Error identifier heap_memory when using Thread library from precompiled boost version 1.46.1
by Lasse Laursen 06 May '11

06 May '11

Hello boostah's, Sorry for the bad bro lingo. I'm having a spot of trouble getting the latest precompiled boost version to work with vs2010. So far I've only added the include directory, added the lib directory and then tried to include the thread.hpp file which results in the following error: Error 1 error C2061: syntax error : identifier 'heap_memory' c:\boost_1_46_1\boost\thread\win32\thread_heap_alloc.hpp 97 1 texsyn I googled this problem-o and found a response asking if the user had any code which replaced the "new" command for debugging purposes. I did have such code and proceeded to comment it out. Unfortunately, no change. Still the same error. Has anyone experienced anything similar and have an idea of how to best proceed? The bestest of all regards in the world, Lasse

1 1

[Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 06 May '11

06 May '11

Hello, Please see the attached headers and test case for a bin_float parser. Please provide comments/suggestions/criticisms. Regards, Vitaly Budovski

3 3

serialization
by grahamo 06 May '11

06 May '11

Hi, I'm working on an atrocious project whereby the persistence/serialization of various objects is done by an internal framework. Data is stored in binary format. Each piece of data is stored with an integer identifier that assicates it with the bindary data. I won't go into the details here. Anyways, this framework is very old and appears to present more problems than it solves. My goal is to convince the project manager that boost serialization is the way to go. They are against external 3rd party libraries despite the fact that boost is maintained by hundreds of developers (perhaps more). If I can provide a persuasive argument to migrating to boost, I can rid this project of a lot of issues. Here's the issues we currently face; A) The objects we persist are very much subject to change. New fields are added, moved around and deleted more or less as the wind blows. With each version of the application, various objects are persisted to disk in a file. This file *must* be compatible with the next version of the application. V1 objects and V2 objects are similar but not always identical (sometimes they are). Migration from V1 to V2 is done by massacring the the codebase with if/else statements. -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-tp3498451p3498451.html Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

mpi all reduce with std::vector and back_inserter
by Kraus Philipp 05 May '11

05 May '11

Hello, I have a std::vector<std::string> vector at each CPU. I would like to "reduce" all vectors on all CPUs. For example: CPU 0: vec = [a, b, c, d] CPU 1: vec = [e, f, g, h] std::vector<std::string> myreduce; mpi::all_reduce( mpi com object, vec, myreduce, #); myreduce = [a, b, c, d, e, f, g, h] How can I do this? Should I replace my # with a back_inserter of the std::vector? Thx for help Phil

2 3