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

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 10 May '06

10 May '06

Ok..let me try that out... Thanks a lot, Priyank -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of JOAQUIN LOPEZ MU?Z Sent: Wednesday, May 10, 2006 12:05 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [multi_index] Core dump in multi-index library !! Patel Priyank-PPATEL1 ha escrito: > Hi Joaquin, > > Seems the problem was happening when I call add and my add method > tries to first find out whether that id is already present in > container or not. It is not during remove method call. (My hunch is that the problem will randomly show at various locations, please keep on reading.) > I was concentrating on wrong portion of the code before. Anyways, I > have changed and put some print out in code also at the end I have > included output that comes. I have changed container to ordered index > as you have said, but seems to be the same problem. This is a very valuable piece of information, and increases my suspicions that the problem lies in your code rather than in B.MI: hashed and ordered indices share almost no code at all, so if the problem persists after switching the index type it's probably because the error lies outside the library. Of course, I might be wrong. > It seems that it is core dumping on following line: > > bool Procedure_Pool::find_by_id(Procedure * _procedure) { > LD_TRACE("Procedure_Pool::find_by_id"); > ACE_ASSERT(_procedure != 0); > ACE_DEBUG((LM_DEBUG, "PROCEDURE TO FIND: %d\n", _procedure->id())); > Procedure_By_Id::iterator it = procedure_by_id_.find(_procedure->id ()); > ACE_DEBUG((LM_DEBUG, "AFTER FIND CALL\n")); return (it != > procedure_by_id_.end()); } > > Please let me know if I am doing something wrong here. Also, let me > know if you need any more information. Please see debug output at the > end of the email. I was consiering two possible causes for the crash in my previous post (leaving out the possibility of a bug in B.MI): 1. Procedure id inadvertently changed. 2. Procedure object deleted before having been removed from the Procedure_Pool. The fact that the crash is now happening in find seems to rule out 1, because inconsistent id's might lead to wrong results in a query, but in no case to a core dump. So, I'd say you are somehow deleting Procedure objects without removing them before from the Procedure_Pool. Maybe you can try to check this as follows: If you can locate all the places in your code where a Procedure object is deleted, i.e expressions of the form: delete p; // p is a Procedure * try instrumenting *all of them* with the following check: if(p != 0){ // Get the pool. I guess you've got some API to do this. Procedure_Hashed_Pool* pool=...; // Since we're deleting p, it musn't still be in pool! assert(pool->find_by_id(p->id()) == 0); } delete p; Do you get an assertion? If so, here's your bug. Please report back. If this doesn't clear up the problem we can explore some other paths. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

getting name of function from boost::function
by chun ping wang 10 May '06

10 May '06

Hmm i have a question, are there ways to get names of the function from boost::function.. example i have void printfuncname(boost::function<void(int)> func) { do some code to print its name. } int main() { boost::function<void(int)> voidint voidint = &somefunc; printfuncname(func); } Thanks...

3 4

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by JOAQUIN LOPEZ MU?Z 10 May '06

10 May '06

Patel Priyank-PPATEL1 ha escrito: > Hi Joaquin, > > Seems the problem was happening when I call add and my add > method tries to first find out whether that id is already > present in container or not. It is not during remove method > call. (My hunch is that the problem will randomly show at various locations, please keep on reading.) > I was concentrating on wrong portion of the code > before. Anyways, I have changed and put some print out in > code also at the end I have included output that comes. I > have changed container to ordered index as you have said, but > seems to be the same problem. This is a very valuable piece of information, and increases my suspicions that the problem lies in your code rather than in B.MI: hashed and ordered indices share almost no code at all, so if the problem persists after switching the index type it's probably because the error lies outside the library. Of course, I might be wrong. > It seems that it is core dumping on following line: > > bool Procedure_Pool::find_by_id(Procedure * _procedure) > { > LD_TRACE("Procedure_Pool::find_by_id"); > ACE_ASSERT(_procedure != 0); > ACE_DEBUG((LM_DEBUG, "PROCEDURE TO FIND: %d\n", _procedure->id())); > Procedure_By_Id::iterator it = procedure_by_id_.find(_procedure->id ()); > ACE_DEBUG((LM_DEBUG, "AFTER FIND CALL\n")); > return (it != procedure_by_id_.end()); > } > > Please let me know if I am doing something wrong here. Also, > let me know if you need any more information. Please see debug > output at the end of the email. I was consiering two possible causes for the crash in my previous post (leaving out the possibility of a bug in B.MI): 1. Procedure id inadvertently changed. 2. Procedure object deleted before having been removed from the Procedure_Pool. The fact that the crash is now happening in find seems to rule out 1, because inconsistent id's might lead to wrong results in a query, but in no case to a core dump. So, I'd say you are somehow deleting Procedure objects without removing them before from the Procedure_Pool. Maybe you can try to check this as follows: If you can locate all the places in your code where a Procedure object is deleted, i.e expressions of the form: delete p; // p is a Procedure * try instrumenting *all of them* with the following check: if(p != 0){ // Get the pool. I guess you've got some API to do this. Procedure_Hashed_Pool* pool=...; // Since we're deleting p, it musn't still be in pool! assert(pool->find_by_id(p->id()) == 0); } delete p; Do you get an assertion? If so, here's your bug. Please report back. If this doesn't clear up the problem we can explore some other paths. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 10 May '06

10 May '06

Hi Joaquin, Sometime also I get following message when I run. I have pure virtual method in Procedure.h file but I have overridden in my Sample_Procedure.h file and implemented there. But still I am getting error relating pure virtual method call. Thanks Priyank // PROCEDURE HEADER #ifndef PROCEDURE_H #define PROCEDURE_H #include <boost/utility.hpp> #include <boost/shared_ptr.hpp> #include <ace/Message_Block.h> #include <ace/Task.h> #include "Procedure_State_Enum.h" #include "Procedure_Type_Enum.h" #include "Loader_Trace.h" class Procedure : boost::noncopyable { public: /** * Virtual destructor. */ virtual Procedure::~Procedure() { } /** * Stats this procedure. * @return Success of failure status of start */ virtual int start() = 0; /** * Handles this message block. Here we can not use scoped pointer since * we have to use release() method that does more than just deleting the * memory allocated. * @param _msg_block Message block to handler by procedure. * @return Indicates success or failure */ virtual int handle(boost::shared_ptr<ACE_Message_Block> _msg_block) = 0; /** * Returns state of the procedure. * @return Success or failure of the procedure. */ virtual const Procedure_State_Enum& state() const = 0; /** * Sets state of the procedure. * @param state to set */ virtual void state(const Procedure_State_Enum& _state) = 0; /** * Id for registration with connection. * @return Id that is used for registration in subscriber. */ virtual int id() const = 0; /** * Returns type of the procedure. * @return type of the procedure. */ virtual const Procedure_Type_Enum& procedure_type() const = 0; /** * This method will be called whenever procedure timed out for incoming * message. Each procedure will register to appropriate reactor (global for now) using * Procedure Timer Handler class and that class will forward the time out method back * to procedure once time out happens. * @param Indicates where timed out handled successfully or not */ virtual void handle_timeout() = 0; }; #endif // SAMPLE PROCEDURE HEADER #ifndef SAMPLE_PROCEDURE_H #define SAMPLE_PROCEDURE_H #include <boost/utility.hpp> #include <boost/scoped_ptr.hpp> #include <ace/Auto_Event.h> #include <ace/Message_Block.h> #include "../../../../core/include/Procedure.h" #include "../../../../core/include/Connection.h" #include "../../../../core/include/Procedure_Timer_Handler.h" #include "../../../../core/include/Logger.h" #include "../../../apps/include/Access_Point.h" class Sample_Procedure : public Procedure { public: /** * Constructor. * @param _ap Access point associated with this procedure. * @param _wait_timer Wait period for receiving message * may not require for real procedure */ Sample_Procedure (Access_Point * _ap, int _recv_timer); /** * Start method will be called when this procedure is activated. */ virtual int start(); /** * Returns state this procedure. * @return Success or failure of the procedure. */ virtual const Procedure_State_Enum& state () const { return state_; } /** * Sets state of the procedure. * @param state to set */ virtual void state(const Procedure_State_Enum& _state) { state_ = _state; } /** * Returns id for this procedure. This has to be unique id * for the procedure. */ virtual int id () const { return id_; } /** * Returns type of the procedure. * @return type of the procedure. */ virtual const Procedure_Type_Enum& procedure_type() const { return type_; } /** * This method will be called whenever procedure timed out for incoming * message. Each procedure will register to appropriate reactor (global for now) using * Procedure Timer Handler class and that class will forward the time out method back * to procedure once time out happens. */ virtual void handle_timeout(); /** * Handles this message block. Here we can not use scoped pointer since * we have to use release() method that does more than just deleting the * memory allocated. * @param _msg_block Message block to handler by procedure. * @return Indicates success or failure */ virtual int handle(boost::shared_ptr<ACE_Message_Block> _msg_block); static int ID; private: /** * Access point for which the procedure is related to. * This is just a temporary storage. User has to pass * each time procedure is created. */ Access_Point* ap_; /** * State of this procedure. */ Procedure_State_Enum state_; /** * State of the procedure. */ Procedure_Type_Enum type_; /** * Wait period to wait. */ int recv_timer_; /** * Procedure timer handler. */ boost::scoped_ptr<Procedure_Timer_Handler> recv_timer_handler_; /** * Created static for this samle procedure. Might be regular * data member for real procedure. */ int id_; }; #endif Thanks, Priyank LD_TRACE: (8) In Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 54 PROCEDURE TO FIND: 1548 pure virtual method called Abort (core dumped) (gdb) where #0 0xfe8d9764 in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xfe8ce978 in _resetsig () from /usr/lib/libthread.so.1 #2 0xfe8ce118 in _sigon () from /usr/lib/libthread.so.1 #3 0xfe8d1158 in _thrp_kill () from /usr/lib/libthread.so.1 #4 0xfea4b9dc in raise () from /usr/lib/libc.so.1 #5 0xfea358fc in abort () from /usr/lib/libc.so.1 #6 0xfeb61208 in __cxxabiv1::__terminate (handler=0xfea357f4 <abort>) at ../../../../gcc-3.3/libstdc++-v3/libsupc++/eh_terminate.cc:47 #7 0xfeb61244 in std::terminate () at ../../../../gcc-3.3/libstdc++-v3/libsupc++/eh_terminate.cc:57 #8 0xfeb61744 in __cxa_pure_virtual () at ../../../../gcc-3.3/libstdc++-v3/libsupc++/pure.cc:50 #9 0x000ce1d8 in _ZNK5boost11multi_index13const_mem_funI9ProcedureiXadsrS2_NKS2_2idEvEEcl ERKS2_ () #10 0x000ce174 in _ZNK5boost11multi_index13const_mem_funI9ProcedureiXadsrS2_NKS2_2idEvEEcl IPS2_EEiRKT_ () #11 0x000ce3e4 in _ZN5boost11multi_index6detail18ordered_index_findINS1_18ordered_index_no deINS1_15index_node_baseIP9ProcedureEEEENS0_13const_mem_funIS5_iXadsrS5_ NKS5_2idEvEEEiSt4lessIiEEEPT_SE_RKT0_RKT1_RKT2_ () #12 0x000cd72c in _ZNK5boost11multi_index6detail13ordered_indexINS0_13const_mem_funI9Proce dureiXadsrS4_NKS4_2idEvEEESt4lessIiENS1_9nth_layerILi1EPS4_NS0_10indexed _byINS0_14ordered_uniqueINS0_3tagI16procedure_id_tagN4mpl_2naESF_SF_SF_S F_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_EES5_SF_EESF_SF_SF_SF_SF_SF_ SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_SF_EESaIS9_EEENS_3mpl6v_itemISD_NSL_ 7vector0ISF_EELi0EEENS1_18ordered_unique_tagEE4findIiEENS1_14index_itera torINS1_18ordered_index_nodeINS1_15index_node_baseIS9_EEEEEERKT_ () #13 0x00064d78 in Procedure_Pool::find_by_id () #14 0x00064650 in Procedure_Pool::add_by_id () #15 0x000783d4 in AP_TCP_Connection::subscribe () #16 0x00069d64 in Access_Point::subscribe () #17 0x00076450 in Procedure_Executor::handle_timeout () #18 0xff2c1940 in ACE_Event_Handler_Handle_Timeout_Upcall<ACE_Recursive_Thread_Mutex>::tim eout () from /vob/wibb_test/tools/cots/ACE_5.5/ace/libACE.so.5.5.0 #19 0xff26f2e4 in ACE_TP_Reactor::handle_timer_events () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #20 0xff26f160 in ACE_TP_Reactor::dispatch_i () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 ---Type <return> to continue, or q <return> to quit---q Quit (gdb) quit // METHOD bool Procedure_Pool::find_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::find_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "PROCEDURE TO FIND: %d\n", _procedure->id())); Procedure_By_Id::iterator it = procedure_by_id_.find(_procedure->id()); ACE_DEBUG((LM_DEBUG, "AFTER FIND CALL\n")); return (it != procedure_by_id_.end()); }

1 0

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 10 May '06

10 May '06

Hi Joaquin, Seems the problem was happening when I call add and my add method tries to first find out whether that id is already present in container or not. It is not during remove method call. I was concentrating on wrong portion of the code before. Anyways, I have changed and put some print out in code also at the end I have included output that comes. I have changed container to ordered index as you have said, but seems to be the same problem. It seems that it is core dumping on following line: bool Procedure_Pool::find_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::find_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "PROCEDURE TO FIND: %d\n", _procedure->id())); Procedure_By_Id::iterator it = procedure_by_id_.find(_procedure->id()); ACE_DEBUG((LM_DEBUG, "AFTER FIND CALL\n")); return (it != procedure_by_id_.end()); } Please let me know if I am doing something wrong here. Also, let me know if you need any more information. Please see debug output at the end of the email. Thanks Priyank #ifndef PROCEDURE_POOL_H #define PROCEDURE_POOL_H /** * Identifier pool of procedure. This procedure will be un-sorted * hashed index provided by procedures unique id retuned by procedure. * It internally uses boost hashed index for indexing the procedures * in procedure pool. * * @author Priyank Patel * @since Mar 30, 2006 */ #include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/hashed_index.hpp> #include <boost/config.hpp> #include <boost/utility.hpp> #include <boost/shared_ptr.hpp> #include <boost/multi_index/key_extractors.hpp> #include "Procedure.h" using boost::multi_index_container; using namespace boost::multi_index; /** * Defines tag used for procedure id. */ struct procedure_id_tag { }; class Procedure_Pool: boost::noncopyable { private: /** * Type definition for multi index container. */ typedef multi_index_container< Procedure*, indexed_by< ordered_unique< tag<procedure_id_tag>, const_mem_fun<Procedure, int, &Procedure::id> > > > Procedure_Hashed_Pool; /** * Type definition for indexing based on procedure id tag. */ typedef Procedure_Hashed_Pool::index<procedure_id_tag>::type Procedure_By_Id; public: /** * Constructor. */ Procedure_Pool(): pool_(), procedure_by_id_(pool_.get<procedure_id_tag>()) { } /** * Adds specified procedure in this pool. * It will intenally used procedures id() method to index procedure. * @param _procedure Procedure to be added in this pool * @return Success (0) or Failure (-1) based on addition happened or not */ int add_by_id(Procedure * _procedure); /** * Removes procedure from this pool. * @param _procedure procedure that needs to be removed * @return Success (0) or Failure (1) based on removal happend or not */ int remove_by_id(Procedure * _procedure); /** * Retrieves procedure based on specified id. * @param _id Identifier * @return Procedure Pointer to procedure. Returns 0 if procedure not found */ Procedure * find_by_id(int _id); private: /** * Returns true if procedure is present otherwise returns false. * @param _procedure procedure that needs to found * @return true if found or false if not found */ bool find_by_id(Procedure * _procedure); /** * boost multiindex object that is associated with this pool. */ Procedure_Hashed_Pool pool_; /** * Refernece of pool that is indexed by procedure id tag. */ Procedure_By_Id &procedure_by_id_; }; #endif #include "../include/Procedure_Pool.h" int Procedure_Pool::add_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::add_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "FIND CALL FROM ADD\n")); if (!find_by_id(_procedure)) { // procedure not found procedure_by_id_.insert(_procedure); // debug info ACE_DEBUG((LM_DEBUG, "Added procedure : %d \n", _procedure->id())); // return success return 0; } else { // error ACE_ERROR((LD_ERROR "%N:%l Error in adding procedure : %d \n", _procedure->id())); // return failure return -1; } } int Procedure_Pool::remove_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::remove_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "FIND CALL FROM REMOVE\n")); if (find_by_id(_procedure)) { // procedure found procedure_by_id_.erase(_procedure->id()); ACE_DEBUG((LM_DEBUG, "Removed procedure : %d \n", _procedure->id())); return 0; } else { ACE_ERROR((LD_ERROR "%N:%l Error in removing procedure : %d \n", _procedure->id())); return -1; } } Procedure * Procedure_Pool::find_by_id(int _id) { LD_TRACE("Procedure_Pool::find_by_id"); Procedure_By_Id::iterator it = procedure_by_id_.find(_id); if (it != procedure_by_id_.end()) { ACE_DEBUG((LM_DEBUG, "%N:%l Found procedure for id: %d \n", _id)); return *it; } ACE_ERROR((LD_ERROR "%N:%l Not able to found procedure for id: %d \n", _id)); // return null return 0; } bool Procedure_Pool::find_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::find_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "PROCEDURE TO FIND: %d\n", _procedure->id())); Procedure_By_Id::iterator it = procedure_by_id_.find(_procedure->id()); ACE_DEBUG((LM_DEBUG, "AFTER FIND CALL\n")); return (it != procedure_by_id_.end()); } Debug Output: ========== May 10 11:12:49.209 2006@isdbuild1@14739@LM_DEBUG@FIND <mailto:2006@isdbuild1@14739@LM_DEBUG@FIND> CALL FROM ADD May 10 11:12:49.209 2006@isdbuild1@14739@LM_TRACE@LD_TRACE <mailto:2006@isdbuild1@14739@LM_TRACE@LD_TRACE> : (8) In Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 54 May 10 11:12:49.209 2006@isdbuild1@14739@LM_DEBUG@PROCEDURE <mailto:2006@isdbuild1@14739@LM_DEBUG@PROCEDURE> TO FIND: 1320 May 10 11:12:49.759 2006@<local_host>@7239@LM_ERROR@Logging <mailto:2006@<local_host>@7239@LM_ERROR@Logging> Service|closing log daemon at host isdbuild1

1 0

[string_algo] trimming Glib::ustring
by Tim Blechmann 10 May '06

10 May '06

hi all, i was trying to use the boost::trim algorithm with Glib::ustring without success ... not sure, if it's a boost or glibmm problem, though ... does anyone have experience with this? thanks ... tim -- TimBlechmann(a)gmx.de ICQ: 96771783 http://www.mokabar.tk Desperation is the raw material of drastic change. Only those who can leave behind everything they have ever believed in can hope to escape. William S. Burroughs

2 2

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 10 May '06

10 May '06

Hi Joaquin, Thanks for your response. Let me try to answer as much as I can for your questions. Also, I am looking in more detail today. It most probably problem in my side. 1. Does this happen the first time remove_by_id() is called or after some running time? => No. I am adding/removing data in multiindex container every 10 millisecond. It runs fine for certain time period without problems. Core dump happens after some time or execution (it varies though 1 min to 5 min or so.) 2. When the crash happens, do you have some debugging tool which allows you to inspect the contents of the _procedure variable passed to remove_by_id()? => I only have gdb. But I am going to put some print out statements in remove_by_id() method and see what it receives. 3. Note that Procedure_Pool holds *pointers* to Procedure. Could it be, when remove_by_id() crashes, that the Procedure object pointed to by _procedure is already deleted? Check the unsubscribe() routines and all the other procedures listed in the stack trace. => Sure. Let me do that and will get back to you on this one. 4. Remember we were talking about why you cannot change directly the Procedure internal variables, but instead you have to use the updating mechanisms provided by Boost.MultiIndex, as described at: http://boost.org/libs/multi_index/doc/tutorial.html#ord_updating The original discussion was at http://lists.boost.org/boost-users/2006/04/18814.php Are you respecting this? Could it be you have inadvertently changed some procedure id by calling some member function of Procedure interface? => Yes. At this point I am not changing anything in procedure object that used by multiindex function calls after creating procedure. Let me verify this one too again. 5. You are using hashed indices, try, just for testing purposes, replacing them with ordered indices (in principle, you will only have to change the Procedure_Hashed_Pool typedef) Rerun: does the crash still persist? => Sure let me try this first. I used hashed index to improve performance. But I can change and try it out. Will get back to you On this one too. First I will try this. Thanks a lot for your reply on this one. Really appreciate your help. Thanks Priyank -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of JOAQUIN LOPEZ MU?Z Sent: Tuesday, May 09, 2006 3:35 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [multi_index] Core dump in multi-index library !! Patel Priyank-PPATEL1 ha escrito: > Hi all, > > I am getting following error in boost multi-index library. I am using > following code to add and remove procedures by id in multi index > container. Can somebody please let me know what might be wrong here? > Really appreciate your quick response on this. [...] Hello Priyank, OK, I've got some questions to ask and some things for you to check. Let's see if we nail the problem down. 1. Does this happen the first time remove_by_id() is called or after some running time? 2. When the crash happens, do you have some debugging tool which allows you to inspect the contents of the _procedure variable passed to remove_by_id()? If so, does the object look OK, or garbled? 3. Note that Procedure_Pool holds *pointers* to Procedure. Could it be, when remove_by_id() crashes, that the Procedure object pointed to by _procedure is already deleted? Check the unsubscribe() routines and all the other procedures listed in the stack trace. 4. Remember we were talking about why you cannot change directly the Procedure internal variables, but instead you have to use the updating mechanisms provided by Boost.MultiIndex, as described at: http://boost.org/libs/multi_index/doc/tutorial.html#ord_updating The original discussion was at http://lists.boost.org/boost-users/2006/04/18814.php Are you respecting this? Could it be you have inadvertently changed some procedure id by calling some member function of Procedure interface? 5. You are using hashed indices, try, just for testing purposes, replacing them with ordered indices (in principle, you will only have to change the Procedure_Hashed_Pool typedef) Rerun: does the crash still persist? Hopefully, some of thes points will shed some more light. Looking fwd to your reporting. On a side note, your code shows a Procedure_Hashed_Pool with only one index, yet you define two views on it, namely pool_ and procedure_by_id_, which are the same. This is at most superfluous, although maybe what you have sent is some reduced form of the original code. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

boost::mpl
by Aleksey Loginov 10 May '06

10 May '06

I got a trouble when used boost::mpl. This code works for std::vector, but fail for std::map (gcc 3.4.2) #include <boost/mpl/apply.hpp> #include <boost/mpl/lambda.hpp> #include <boost/type_traits/is_same.hpp> #include <iostream> #include <vector> #include <map> #include <utility> namespace mpl=boost::mpl; template<typename Pair> struct first { typedef typename Pair::first_type type; }; template<typename Pair> struct second { typedef typename Pair::second_type type; }; int main () { typedef mpl::lambda< std::vector< second< mpl::arg<1> > > > vector; std::cout << boost::is_same< mpl::apply<vector, std::pair<char,int> >::type, std::vector<int> >::value << std::endl; typedef mpl::lambda< std::map< first< mpl::arg<1> >, second< mpl::arg<1> > > > map; std::cout << boost::is_same< mpl::apply<map, std::pair<char,int> >::type, std::map<char,int> >::value << std::endl; return 0; } Simple tests show that problem in std::allocator< std::pair<const Key,Type> > Looks like compiler bug, but may be it's my error. Any thought's how avoid the problem?

1 0

Poll: Are you stuck on an old Boost release due to a defective compiler?
by Nicola Musatti 10 May '06

10 May '06

Hallo, I'm trying to gauge the number of Boost users that are actually using an older version of the libraries because they have to use a compiler that's not supported by more recent versions of the libraries they use. As for myself, I work on a project where Borland's BCB6 is used and we're stuck with Boost 1.31 mostly because more recent versions of uBlas do not work with our compiler. Cheers, Nicola Musatti

5 7

program_options questions
by Roel 10 May '06

10 May '06

Hi, I've been using boost::program_options but I have some questions about it. First: to catch errors that the users makes when specifying command-line options (eg I declared an option to be integer-only but the user specified a string), I surrounded the call to store() by a try/catch block: try { boost::program_options::store( boost::program_options::command_line_parser(argc, argv). options(desc).positional(p).run(), vm); } catch (boost::program_options::invalid_option_value e) { } But now how do I give a meaningfull error message? The what() function of invalid_option_value is private, what other options do I have? Secondly, is there a mechanism to check the relation between options? I have a number of options: -a, -m and -d for add, modify and delete respectively; I want only one of them to be allowed at the same time. Also, when the -a option is specified, the -t and -r options are valid, and only then. Do I have to check all of that manually? Thanks. cheers, roel

2 1