- Boost-users - lists.boost.org

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

RE: [Boost-users] RE: Boost thread problem
by Sliwa, Przemyslaw (London) 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. Thanks for help, Pshemek -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of C. Michailidis Sent: 14 April 2005 07:26 To: boost-users(a)lists.boost.org Subject: [Boost-users] RE: Boost thread problem > All, > > I have got a problem with the boost::thread package. > My idea was to facilitate the multiprocessor ability of my computer and > write a program which creates 10 threads which firstly write to the disk > certain amount of information and then they read it back and push back > certain objects. I am getting some memory access problems when pushing > back the objects to the global vector. Can anyone of you understand why > there is a problem? I really do not get it since the mutex is locked and > the access to the vector is exclusively guaranteed to the active thread. > > > Can you help? I tried your code on my system and it seems to work as expected. No exceptions were thrown, there was a file called 'file.txt' in the pwd, and TradeVector.size was 80000 after the run. Of course I needed to remove the include of proprietary code - it was replaced with a dummy/stub class like this one: class CFXTrade { public: CFXTrade() { }; CFXTrade( int id, string name, double amt ) { m_TradeID = id; m_Name = name; m_Amount = amt; }; int m_TradeID; string m_Name; double m_Amount; }; My system looks like this: FreeBSD medea.digitalescorts.net 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #0: Thu Mar 31 02:47:38 EST 2005 root@medea.digitalescorts.net:/usr/obj/usr/src/sys/MEDEA i386 and I have boost-1.32.0_2 libraries installed. I built the program from the command-line using the following command: "gcc hello.cpp -ggdb -I/usr/local/include -L/usr/local/lib -lboost_thread -lc_r" The problem may be platform specific. Are you linking against a thread-safe CRT? Can you provide details regarding your operating system? Which version of the boost library do you have installed? My suspicion is that you may not be using a thread-safe CRT. Of course the boost_thread library may be broken for your specific platform (but I doubt it). Sincerely, Constantino Michailidis Balston Research LLC _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

2 1

uBLAS and stl algorithms
by Pascal Bauer 14 Apr '05

14 Apr '05

Hi List Members I have data stored in an matrix. Now, i want to acces the data of the matrix row-wise. because i want to access it in a sorted manner (without moving the matrix entries around), i make a stl-vector of matrix_rows. This works fine. But if i now use the stl algorithms to sort the stl-vector by a certain criteria, then it happens, that the algorithm is making several copies of a singe vector entry and overwriting other entries. Can anyone give me a tipp, what i'm doing wrong? ---------------------------- Here is an example code: #include<iostream> #include<vector> #include<algorithm> #include<cmath> #include<boost/numeric/ublas/matrix.hpp> #include<boost/numeric/ublas/io.hpp> namespace num=boost::numeric::ublas; template <int N> class Ordering { public: bool operator()(num::matrix_row<num::matrix<double> > A, num::matrix_row<num::matrix<double> > B) { if (A(N) < B(N) ) return true; else return false; } }; int main(int argc, char* argv[]) { const int N = 10000; const int M = 4; num::matrix<double> Matrix(N, M); for (int i = 0; i < Matrix.size1(); i++) { for (int j = 0; j < Matrix.size2(); j++) { Matrix(i, j) = drand48(); } } std::vector<num::matrix_row<num::matrix<double> > > MyAccess; for (int i = 0; i < Matrix.size1(); i++) { MyAccess.push_back(num::matrix_row<num::matrix<double> >(Matrix, i) ); } for (int i = 0; i < Matrix.size1(); i++) { std::cout << MyAccess[i] << std::endl; } std::sort(MyAccess.begin(), MyAccess.end(), Ordering<0>() ); for (int i = 0; i < Matrix.size1(); i++) { std::cout << MyAccess[i] << std::endl; } }

1 0

RE: [Boost-users] RE: Boost thread problem
by Sliwa, Przemyslaw (London) 14 Apr '05

14 Apr '05

Well, I have tried it on three systems: 1 multiprocessor Win XP -> fails, some problems with the heap, 2. single processor Win 2000 -> works fine, no problems at all, all the treads exit properly, 3. single processor Linux Suse 9.1, gcc 3.3 -> fails, segmentation fault. I am also using the boost 1.32 library. Similar compilation on Linux except -lc_r. What is it for? How to check if I am linking against thread safe libraries? On Windows the NET 2003 compiler was used, the multithreaded support was on, so I have no idea how to link against tread safe libs. Can you advise? Thanks in advance Pshemek -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of C. Michailidis Sent: 14 April 2005 07:26 To: boost-users(a)lists.boost.org Subject: [Boost-users] RE: Boost thread problem > All, > > I have got a problem with the boost::thread package. > My idea was to facilitate the multiprocessor ability of my computer and > write a program which creates 10 threads which firstly write to the disk > certain amount of information and then they read it back and push back > certain objects. I am getting some memory access problems when pushing > back the objects to the global vector. Can anyone of you understand why > there is a problem? I really do not get it since the mutex is locked and > the access to the vector is exclusively guaranteed to the active thread. > > > Can you help? I tried your code on my system and it seems to work as expected. No exceptions were thrown, there was a file called 'file.txt' in the pwd, and TradeVector.size was 80000 after the run. Of course I needed to remove the include of proprietary code - it was replaced with a dummy/stub class like this one: class CFXTrade { public: CFXTrade() { }; CFXTrade( int id, string name, double amt ) { m_TradeID = id; m_Name = name; m_Amount = amt; }; int m_TradeID; string m_Name; double m_Amount; }; My system looks like this: FreeBSD medea.digitalescorts.net 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #0: Thu Mar 31 02:47:38 EST 2005 root@medea.digitalescorts.net:/usr/obj/usr/src/sys/MEDEA i386 and I have boost-1.32.0_2 libraries installed. I built the program from the command-line using the following command: "gcc hello.cpp -ggdb -I/usr/local/include -L/usr/local/lib -lboost_thread -lc_r" The problem may be platform specific. Are you linking against a thread-safe CRT? Can you provide details regarding your operating system? Which version of the boost library do you have installed? My suspicion is that you may not be using a thread-safe CRT. Of course the boost_thread library may be broken for your specific platform (but I doubt it). Sincerely, Constantino Michailidis Balston Research LLC _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

1 0

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

14 Apr '05

> OK, this is a different story. Yes, unfortunately. > 2. The comparison predicate you're passing is not correct (i.e. it > does not implement a strict weak ordering.) OK, this is possible. I'm using a function object. What exactly does it mean to implement strict weak ordering? I need to search the documentation again... > 3. Elements are dynamic (pointers to objects) and you did > a premature delete on one or some of them. I'm using boost::shared_ptr types, so they shouldn't get cleaned up while they are contained by the MultiIndexSet. However, I'm starting to suspect that the shared_ptrs are not behaving well. > 5. You're running out of memory and new() does not throw bad_alloc > (this can happen in MSVC++ 6.5 and, maybe, 7.0.) I'm using gcc on RHEL3; I don't believe this is happening. > 6. You haven't > selected a multithreaded version of the runtime library. I need to investigate this; what 'runtime library' are you referring to? > 7. You > guarded write access to an index but *not* to other indices of the > same container. I gaurded ~everything~ ;) > Questions: > > 1. I'd like to analyze this. I can run tests in GCC/Cygwin. Could your > test be run on this platform? If not, could you at least disclose the > code so that I can take a look at it? We're developing on the linux platform, so that's not a barrier, but unfortunately, it will be very difficult to convince my employer to allow me to disclose any code. Thank you, however, for offering to analyze it. > 2. Does your > debugging environment allow you to peek at the variables when the > assert happens? I'm using some acient version of gdb/ddd. I could try, although I'm not sure how to do that yet. > Thank *you* for reporting the problem. Sure, although it's probably something I'm doing wrong. I really do appreciate your help. This MultiIndexSet is perfect for my needs; I just need to get it working right!

2 1

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

14 Apr '05

> All, > > I have got a problem with the boost::thread package. > My idea was to facilitate the multiprocessor ability of my computer and > write a program which creates 10 threads which firstly write to the disk > certain amount of information and then they read it back and push back > certain objects. I am getting some memory access problems when pushing > back the objects to the global vector. Can anyone of you understand why > there is a problem? I really do not get it since the mutex is locked and > the access to the vector is exclusively guaranteed to the active thread. > > > Can you help? I tried your code on my system and it seems to work as expected. No exceptions were thrown, there was a file called 'file.txt' in the pwd, and TradeVector.size was 80000 after the run. Of course I needed to remove the include of proprietary code - it was replaced with a dummy/stub class like this one: class CFXTrade { public: CFXTrade() { }; CFXTrade( int id, string name, double amt ) { m_TradeID = id; m_Name = name; m_Amount = amt; }; int m_TradeID; string m_Name; double m_Amount; }; My system looks like this: FreeBSD medea.digitalescorts.net 5.4-PRERELEASE FreeBSD 5.4-PRERELEASE #0: Thu Mar 31 02:47:38 EST 2005 root@medea.digitalescorts.net:/usr/obj/usr/src/sys/MEDEA i386 and I have boost-1.32.0_2 libraries installed. I built the program from the command-line using the following command: "gcc hello.cpp -ggdb -I/usr/local/include -L/usr/local/lib -lboost_thread -lc_r" The problem may be platform specific. Are you linking against a thread-safe CRT? Can you provide details regarding your operating system? Which version of the boost library do you have installed? My suspicion is that you may not be using a thread-safe CRT. Of course the boost_thread library may be broken for your specific platform (but I doubt it). Sincerely, Constantino Michailidis Balston Research LLC

1 0