April 2005 - Boost-users - lists.boost.org

building boost w/o debug libs
by Daniel Goller 15 Apr '05

15 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i can't locate it in the docs where it explains how not to build the debug libs, i found it where i could exlude certain libs, build oooonly some, or build not the threaded libs, if i missed it a kind nudge in the right direction would be appreciated, or if not in docs, a simple sample option to bjam would be highly appreciated thank you in advance for your efforts Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCXcSmUpKYMelfdYERAibsAJ9Rh3nSBWCDPWI4xs28//8M0BxExACdEOo0 6k14l84CKaEeMwORIRdxvDM= =HHCY -----END PGP SIGNATURE-----

3 3

boost::shared_ptr and stl algorithms
by Bill Eidson 15 Apr '05

15 Apr '05

std::vector< boost::shared_ptr<T> > TVec; I want to write a function object to run std::for_each. to do somework against members of T and accumulate results in functor. My attempts have failed in VC7 with memory errors in my operator() method. struct fo { bool operator()( boost::shared_ptr<T>& t ) { return true; } }; Thanks in advance bille

5 9

RE: [Boost-users] Re: MultiIndexSet invariant test failure
by Manges, Ross G 14 Apr '05

14 Apr '05

Joaquin M Lopez Munoz wrote: > Two (main) possibilities: the shared_ptr is invalid or > my code has a bug. Could you test the pointer for validity before > making the insertion? > > m.check_invariant_(); > // check ptr before insertion > m.insert(ptr); OK, so I print out the members of the object that the shared_ptr encapsulates, and it appears that the shared_ptr object is OK before insertion. > If still the error is detected inside insert(), we can try to produce > some sort of poorman dump of the container: define > BOOST_MULTI_INDEX_INVARIANT_ASSERT to throw an exception on failure > and wrap the call to insert() as follows: OK, I tried to use the following code, and recompiled, but I don't catch the exception, and in turn I see rather unpredictable behavior before my program dies violently. Is my macro definition incorrect? //************* begin **************** struct invariant_exception { invariant_exception() {} }; #define BOOST_MULTI_INDEX_INVARIANT_ASSERT(expr) \ if(!(expr)){throw invariant_exception();} //************* end ***************** > try{ > m.insert(...); > } > catch(/* exception thrown by the assert */){ > // dump the contents of m > } > > Can you do that? Notice something weird in the dump? > Can you post the dump? I will post the dump if I can get it to create one. Thanks for your perseverance! --Ross

1 0

RE: Boost thread problem
by C. Michailidis 14 Apr '05

14 Apr '05

> It seems the usage of the vector cases problems with the multithreaded programs on the multiprocessor machines. > I have changed it to queue and the bug has been resolved. I cannot reproduce it now. Huh, that's interesting! I suppose it may no longer be a major issue for you then (even though vectors and queues have different algorithms under the hood). Because you mentioned that the problem seems to be limited to true SMP systems, I tried your code again (this time on a dual cpu system) and I still couldn't reproduce it. I must admit that the process didn't seem to bounce between cpus though, so perhaps something is lost in the shuffle in that regard. The dual cpu system was configured similarly to the first machine that I tried it on (FreeBSD 5.3 + boost 1.32.0_2). The first machine (although not a 'true' smp system) is using hyperthreading w/ an SMP kernel so as far as the OS is concerned it too is a multiprocessor machine. If you still want to isolate the problem that you *were* having (using vector) then you may be interested in the details of thread-safe CRTs. The "-lc_r" indicates that (on FreeBSD) the re-entrant C library (i.e. thread-safe) should be linked against. On Windows I believe the analog is called something like 'msvcrtmt.dll' (C RunTime - MultiThreaded). I would hope that the .NET compiler uses this 'msvcrtmt.dll' when 'multithreaded support is on', but I couldn't tell you for sure. If you're statically linking, I think the name is just 'msvcrtmt.lib'. The thread-unsafe version doesn't have 'mt' appended to the library filename. The glamour of MSFT development has been largely replaced with a desire to actually get stuff working so... most of my development has been on FreeBSD lately. Therefore some of this MSFT specific information may not be exactly correct. Oh how the cobwebs accumulate! Anyway, you could probably double check for the 'msvcrtmt' library by looking at the detailed linker settings, that is if my suspicion concerns you and you're still interested in isolating the problem. In any case, I'm glad you found a work-around! C. Michailidis Balston Research LLC

1 0

RE: [Boost-users] Re: MultiIndexSet invariant test failure
by Manges, Ross G 14 Apr '05

14 Apr '05

Joaquin M Lopez Munoz wrote: > You've got to implement semantics equivalent to that of > the < relationship between numbers: Thanks for the info; I now believe I'm doing this correctly. > * Now, in the piece of your code where the insert asserts, > add a precheck of the invariant: > > m.check_invariant_(); // point A > m.insert(...); // point B > > * Run your test till the assert fires. Is it in point > A or B? If A, then most likely you're somehow modifying > the elements in some other thread. Get the idea? This is a great idea! I added the precheck as you suggested, and it appears that I am experiencing the assert in 'point B'. The invariant is OK until the insertion breaks it. So can I infer that somehow what I'm inserting is invalid? It's a shared_ptr. I recently sent in another post regarding problems I'm having with shared_ptrs that might be related (see post w/subject: "shared_ptr use_count in multi threaded environment"). Thanks!

2 1

Boost.test compile warning
by Sean DeNigris 14 Apr '05

14 Apr '05

When using the static single-threaded debug version of Boost.test, I'm getting the following warning: c:\Program Files\Programming\Boost\include\boost-1_32_vc7_1\boost\test\detail\wrap_stri ngstream.hpp(69) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data c:\Program Files\Programming\Boost\include\boost-1_32_vc7_1\boost\test\test_tools.hpp(4 35) : see reference to function template instantiation 'boost::basic_wrap_stringstream<CharT> &boost::operator <<<char,size_t>(boost::basic_wrap_stringstream<CharT> &,const T &)' being compiled with [ CharT=char, T=size_t ] e:\My Projects\OrderPro\OrderProTest\OrderTest.cpp(55) : see reference to function template instantiation 'bool boost::test_tools::tt_detail::equal_and_continue_impl<std::string,const char[9]>(const Left &,Right (&),boost::wrap_stringstream &,boost::test_tools::const_string,size_t,boost::unit_test::log_level,size_t) ' being compiled with [ Left=std::string, Right=const char [9] ] Any ideas? - Sean

1 0

RE: [Boost-users] shared_ptr use_count in multi threaded environment
by Manges, Ross G 14 Apr '05

14 Apr '05

> - Is it possible that some parts of your code are compiled without > BOOST_HAS_THREADS? I updated user.hpp and then executed: % bjam clean % bjam install I assume that is sufficient to recompile all of the boost code? > - Is it possible that you are assigning to the shared_ptr<Connector> > object > and at the same time reading it (making a copy of it, for example) or > even assigning or resetting it from a different thread? It might be a possibility; I'll sift through the code to see if I can find any situations like this. Thanks!

1 0

shared_ptr use_count in multi threaded environment
by Manges, Ross G 14 Apr '05

14 Apr '05

I've been experiencing trouble with shared_ptrs in a multithreaded environment. First, I noticed that the ref count wasn't being locked when updated by multiple threads (shared_count.hpp). I recompiled the boost library with BOOST_HAS_THREADS defined the user.hpp, and now I can verify that the scoped_lock is being used, but I'm still seeing the same kind of problems. The traces happen in different places each time, but in general it appears that the ref count is being decremented to zero inappropriately, which in turn sometimes causes the dreaded "assert px != 0" message. See the example traces below. Please let me know if you have any suggestions on how I might proceed to debug this problem. Thanks! message that preceeded "trace A": main: /.../boost-1_32/boost/shared_ptr.hpp:253: T* boost::shared_ptr<T>::operator->() const [with T = Connector]: Assertion `px != 0' failed. ======== trace A with px != 0 assert ============ #0 0xb70d6e01 in kill () from /lib/i686/libc.so.6 #1 0xb6f641ed in pthread_kill () from /lib/i686/libpthread.so.0 #2 0xb6f6458b in raise () from /lib/i686/libpthread.so.0 #3 0xb70d6ba4 in raise () from /lib/i686/libc.so.6 #4 0xb70d805d in abort () from /lib/i686/libc.so.6 #5 0xb70cfe99 in __assert_fail () from /lib/i686/libc.so.6 #6 0xb73aac75 in boost::shared_ptr<Connector>::operator-> ( this=0xb6710d24) at shared_ptr.hpp:253 #7 0xb73a98b1 in Listener::run ( this=0x8089af0) at Adapter.cpp:974 #8 0xb74d37be in ost::ThreadImpl::ThreadExecHandler (th=0x8089af0) at thread.cpp:1110 #9 0xb74d29bf in ccxx_exec_handler (th=0x8089af0) at thread.cpp:1136 #10 0xb6f61e21 in pthread_start_thread () from /lib/i686/libpthread.so.0 #11 0xb718c08a in clone () from /lib/i686/libc.so.6 ======== trace B, no px != 0 assert ============ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 81926 (LWP 18562)] 0xb6f62232 in pthread_mutex_lock () from /lib/i686/libpthread.so.0 (gdb) bt #0 0xb6f62232 in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #1 0xb71997ef in pthread_mutex_lock () from /lib/i686/libc.so.6 #2 0x0806bf45 in scoped_lock (this=0xb65e0b64, m=@0x27) at lwm_pthreads.hpp:72 #3 0x0806ba29 in boost::detail::sp_counted_base::add_ref_copy (this=0x1b) at shared_count.hpp:122 #4 0x0806a98d in boost::detail::shared_count::operator= (this=0xb65e0ce8, r=@0xb6c01b1c) at shared_count.hpp:400 #5 0xb73aac18 in boost::shared_ptr<Connector>::operator= ( this=0xb65e0ce4, r=@0xb6c01b18) at shared_ptr.hpp:148 #6 0xb73a974e in Listener::run ( this=0xb6c02f68) at Adapter.cpp:966 #7 0xb74d37be in ost::ThreadImpl::ThreadExecHandler (th=0xb6c02f68) at thread.cpp:1110 #8 0xb74d29bf in ccxx_exec_handler (th=0xb6c02f68) at thread.cpp:1136 #9 0xb6f61e21 in pthread_start_thread () from /lib/i686/libpthread.so.0 #10 0xb6f61fb5 in pthread_start_thread_event () from /lib/i686/libpthread.so.0 #11 0xb718c08a in clone () from /lib/i686/libc.so.6

2 1

Spotted: use of Boost.Python
by Jim.Hyslop 14 Apr '05

14 Apr '05

For those interested in keeping track of who's using Boost, the game "Civilization IV" uses Boost.Python to interface to its C++ components: http://forums.civfanatics.com/showthread.php?t=108315 <http://forums.civfanatics.com/showthread.php?t=108315> Just thought some people might like to know. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com <http://www.leitch.com> ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts <http://www.cuj.com/experts> )

1 0

Unit Test question: BOOST_CHECK_MESSAGE and high logging levels
by Dave Steffen 14 Apr '05

14 Apr '05

Folks, I just noticed something: a unit test with something like this BOOST_CHECK_MESSAGE ( true, "this should never be seen" ); will, of course, be silent when run... unless you've got the logging turned all the way up. When run with --log_level=all --report_level=detailed this turns up in the output: ./../util/unitTest/test_auto.C(32): info: this should never be seen Is this intentional? It is suprising to me... if the message in the check says something about "failing" or "errors", the output appears to be signaling a unit test failure when really it isn't. Am I missing something? Thanks!! ---------------------------------------------------------------------- Dave Steffen, Ph.D. "Irrationality is the square root of all evil" Software Engineer IV -- Douglas Hofstadter Numerica Corporation ph (970) 419-8343 x27 "Oppernockity tunes but once." -- anon. fax (970) 223-6797 dgsteffen(a)numerica.us ___________________ Numerica Disclaimer: This message and any attachments are intended only for the individual or entity to which the message is addressed. It is proprietary and may contain privileged information. If you are neither the intended recipient nor the agent responsible for delivering the message to the intended recipient, you are hereby notified that any review, retransmission, dissemination, or taking of any action in reliance upon, the information in this communication is strictly prohibited, and may be unlawful. If you feel you have received this communication in error, please notify us immediately by returning this Email to the sender and deleting it from your computer.

2 2