- Boost-users - lists.boost.org

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

10 May '06

----- Mensaje original ----- De: Patel Priyank-PPATEL1 <priyankpatel(a)motorola.com> Fecha: Miércoles, Mayo 10, 2006 10:49 pm Asunto: Re: [Boost-users] [multi_index] Core dump in multi-index library !! > Hi Joaquin, [...] > One other thing, addition and deletionIs done by separate > threads in my application. Oh, oh. multi_index_container is *not* thread safe, so this smells like the problem --and it is not, it certainly has the potential to crash your app sooner or later. Please take into account thread unsafety extends to every member function of multi_index_container, so you'd better lockguard *every* public method of Procedure_Pool. Looking fwd to knowing your results. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo In case you're wondering, STL implementations typically have the same level of thread safety as B.MI provides: 1. Concurrent access to different containers is safe. 2. Concurrent read-only access to the same container is safe. The rationale is that locking every public method of an STL container adds an unavoidable runtime overhead (you might not need it), and moreover it doesn't necessarily map to what constitutes *atomicity* to a given app --in your case, for instance, atomicity, and thus lockguarding, is best done at the level of Procedue_Pool interface.

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, As I said, I think the problem is during addition and not delete. I have tried to build my application with debug mode and have some more printouts for you. Please let me know if this helps or not. Everything goes smooth for a while but suddenly it stops working. I even Removed delete calls but the problem still exists. One other thing, addition and deletion Is done by separate threads in my application. I am trying now to lock/unlock pool when I do addition/deletion and see whether that works or not. Let me know if you need any More information relating this. Thanks a lot for your help. Thread id (8) adds procedures in procedure pool while thread id (4) removes Procedure from procedure pool. // SOME TRACE WHILE EXECUTING LD_TRACE: (8) In Method: Procedure_Executor::handle_timeout File: `src/apps/executor/Procedure_Executor.cpp' Line: 67 LD_TRACE: (8) In Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) Out Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) In Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) Out Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) In Method: Sample_Procedure::Sample_Procedure File: `src/apps/procedure/Sample_Procedure.cpp' Line: 9 LD_TRACE: (8) Out Method: Sample_Procedure::Sample_Procedure File: `src/apps/procedure/Sample_Procedure.cpp' Line: 9 LD_TRACE: (8) In Method: Access_Point::subscribe File: `src/apps/network_element/Access_Point.cpp' Line: 181 LD_TRACE: (8) In Method: AP_TCP_Connection::subscribe File: `src/apps/connector/AP_TCP_Connection.cpp' Line: 81 LD_TRACE: (8) In Method: Procedure_Pool::add_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 5 FIND CALL FROM ADD LD_TRACE: (8) In Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 41 src/core/procedure/Procedure_Pool.cpp:47 Not able to found procedure for id: 1646 LD_TRACE: (8) Out Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 41 Added procedure : 1646 LD_TRACE: (8) Out Method: Procedure_Pool::add_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 5 src/apps/connector/AP_TCP_Connection.cpp:88 Subscribed sample type procedure LD_TRACE: (8) Out Method: AP_TCP_Connection::subscribe File: `src/apps/connector/AP_TCP_Connection.cpp' Line: 81 LD_TRACE: (8) Out Method: Access_Point::subscribe File: `src/apps/network_element/Access_Point.cpp' Line: 181 LD_TRACE: (8) In Method: Sample_Procedure::start File: `src/apps/procedure/Sample_Procedure.cpp' Line: 15 LD_TRACE: (8) In Method: Procedure_Timer_Handler::schedule File: `src/core/procedure/Procedure_Timer_Handler.cpp' Line: 5 Timer id 24 scheduled. LD_TRACE: (8) Out Method: Procedure_Timer_Handler::schedule File: `src/core/procedure/Procedure_Timer_Handler.cpp' Line: 5 LD_TRACE: (8) In Method: Tcp_Connection::send File: `src/core/connector/Tcp_Connection.cpp' Line: 78 src/core/connector/Tcp_Connection.cpp:92 Sent 4 bytes on: Remote IP 173.6.64.7 , Remote Port 30501 Local Ip 173.6.64.7 Local Port 30000 LD_TRACE: (8) Out Method: Tcp_Connection::send File: `src/core/connector/Tcp_Connection.cpp' Line: 78 SENT=> P_ID: 1646 HEXDUMP 4 bytes 00 00 06 6e ...n LD_TRACE: (8) Out Method: Sample_Procedure::start File: `src/apps/procedure/Sample_Procedure.cpp' Line: 15 LD_TRACE: (8) Out Method: Procedure_Executor::handle_timeout File: `src/apps/executor/Procedure_Executor.cpp' Line: 67 LD_TRACE: (4) In Method: Tcp_Handler::handle_input File: `src/core/connector/Tcp_Handler.cpp' Line: 38 src/core/connector/Tcp_Handler.cpp:43 Received 4 bytes LD_TRACE: (4) Out Method: Tcp_Handler::handle_input File: `src/core/connector/Tcp_Handler.cpp' Line: 38 LD_TRACE: (4) In Method: Tcp_Handler::handle_output File: `src/core/connector/Tcp_Handler.cpp' Line: 73 src/core/connector/Tcp_Handler.cpp:78 Successfully dequeued messageLD_TRACE: (4) In Method: AP_TCP_Connection::handle File: `src/apps/connector/AP_TCP_Connection.cpp' Line: 119 LD_TRACE: (4) In Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 41 src/core/procedure/Procedure_Pool.cpp:44 Found procedure for id: 1646 LD_TRACE: (4) Out Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 41 FOUND PROCEDURE FOR ID: 1646 LD_TRACE: (4) In Method: Sample_Procedure::handle File: `src/apps/procedure/Sample_Procedure.cpp' Line: 53 RECV<= P_ID: 1646 HEXDUMP 4 bytes 00 00 06 6e ...n LD_TRACE: (4) In Method: Access_Point::unsubscribe File: `src/apps/network_element/Access_Point.cpp' Line: 196 src/apps/network_element/Access_Point.cpp:199 UNSUBCRIBING: 1646 LD_TRACE: (4) In Method: AP_TCP_Connection::unsubscribe File: `src/apps/connector/AP_TCP_Connection.cpp' Line: 99 src/apps/connector/AP_TCP_Connection.cpp:103 UNSUBCRIBING: 1646 LD_TRACE: (4) In Method: Procedure_Pool::remove_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 25 REMOVING: 1646 LD_TRACE: (4) In Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 41 src/core/procedure/Procedure_Pool.cpp:44 Found procedure for id: 1646 LD_TRACE: (4) Out Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 41 Removed procedure : 1646 LD_TRACE: (4) Out Method: Procedure_Pool::remove_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 25 src/apps/connector/AP_TCP_Connection.cpp:108 UnSubscribed sample type procedureLD_TRACE: (4) Out Method: AP_TCP_Connection::unsubscribe File: `src/apps/connector/AP_TCP_Connection.cpp' Line: 99 LD_TRACE: (4) Out Method: Access_Point::unsubscribe File: `src/apps/network_element/Access_Point.cpp' Line: 196 LD_TRACE: (4) In Method: Procedure_Timer_Handler::cancel File: `src/core/procedure/Procedure_Timer_Handler.cpp' Line: 31 Timer id 24 cancelled. LD_TRACE: (4) Out Method: Procedure_Timer_Handler::cancel File: `src/core/procedure/Procedure_Timer_Handler.cpp' Line: 31 DELETING PROCEDURE: 1646 LD_TRACE: (4) Out Method: Sample_Procedure::handle File: `src/apps/procedure/Sample_Procedure.cpp' Line: 53 LD_TRACE: (4) Out Method: AP_TCP_Connection::handle File: `src/apps/connector/AP_TCP_Connection.cpp' Line: 119 src/core/connector/Tcp_Handler.cpp:91 Successfully send message block to connectorLD_TRACE: (4) Out Method: Tcp_Handler::handle_output File: `src/core/connector/Tcp_Handler.cpp' Line: 73 LD_TRACE: (4) In Method: Procedure_Timer_Handler::handle_timeout File: `src/core/include/Procedure_Timer_Handler.h' Line: 37 LD_TRACE: (4) In Method: Sample_Procedure::handle_timeout File: `src/apps/procedure/Sample_Procedure.cpp' Line: 41 LD_TRACE: (4) Out Method: Sample_Procedure::handle_timeout File: `src/apps/procedure/Sample_Procedure.cpp' Line: 41 LD_TRACE: (4) Out Method: Procedure_Timer_Handler::handle_timeout File: `src/core/include/Procedure_Timer_Handler.h' Line: 37 LD_TRACE: (8) In Method: Procedure_Executor::handle_timeout File: `src/apps/executor/Procedure_Executor.cpp' Line: 67 LD_TRACE: (8) In Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) Out Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) In Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) Out Method: Access_Points::next File: `src/apps/network_element/Access_Points.cpp' Line: 48 LD_TRACE: (8) In Method: Sample_Procedure::Sample_Procedure File: `src/apps/procedure/Sample_Procedure.cpp' Line: 9 LD_TRACE: (8) Out Method: Sample_Procedure::Sample_Procedure File: `src/apps/procedure/Sample_Procedure.cpp' Line: 9 LD_TRACE: (8) In Method: Access_Point::subscribe File: `src/apps/network_element/Access_Point.cpp' Line: 181 LD_TRACE: (8) In Method: AP_TCP_Connection::subscribe File: `src/apps/connector/AP_TCP_Connection.cpp' Line: 81 LD_TRACE: (8) In Method: Procedure_Pool::add_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 5 FIND CALL FROM ADD LD_TRACE: (8) In Method: Procedure_Pool::find_by_id File: `src/core/procedure/Procedure_Pool.cpp' Line: 41 Segmentation fault (core dumped) // STACK TRACE (gdb) where #0 0x00000000 in ?? () #1 0x000ce15c in _ZNK5boost11multi_index13const_mem_funI9ProcedureiXadsrS2_NKS2_2idEvEEclERKS2_ (this=0x187548, x=@0x16d2a0) at /vob/wibb_test/tools/cots/boost/boost/multi_index/mem_fun.hpp:60 #2 0x000ce0f8 in _ZNK5boost11multi_index13const_mem_funI9ProcedureiXadsrS2_NKS2_2idEvEEclIPS2_EEiRKT_ (this=0x187548, x=@0x1345b0) at /vob/wibb_test/tools/cots/boost/boost/multi_index/mem_fun.hpp:55 #3 0x000ce368 in _ZN5boost11multi_index6detail18ordered_index_findINS1_18ordered_index_nodeINS1_15index_node_baseIP9ProcedureEEEENS0_13const_mem_funIS5_iXadsrS5_NKS5_2idEvEEEiSt4lessIiEEEPT_SE_RKT0_RKT1_RKT2_ (header=0x134598, key=@0x187548, x=@0xfe407618, comp=@0x187549) at /vob/wibb_test/tools/cots/boost/boost/multi_index/detail/ord_index_ops.hpp:65 #4 0x000cd6b0 in _ZNK5boost11multi_index6detail13ordered_indexINS0_13const_mem_funI9ProcedureiXadsrS4_NKS4_2idEvEEESt4lessIiENS1_9nth_layerILi1EPS4_NS0_10indexed_byINS0_14ordered_uniqueINS0_3tagI16procedure_id_tagN4mpl_2naESF_SF_SF_SF_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_iteratorINS1_18ordered_index_nodeINS1_15index_node_baseIS9_EEEEEERKT_ (this=0x187548, x=@0xfe407618) at /vob/wibb_test/tools/cots/boost/boost/multi_index/ordered_index.hpp:376 #5 0x00064af0 in Procedure_Pool::find_by_id (this=0x187540, _id=1647) at src/core/procedure/Procedure_Pool.cpp:42 #6 0x0006462c in Procedure_Pool::add_by_id (this=0x187540, _procedure=0x173cd0) at src/core/procedure/Procedure_Pool.cpp:8 #7 0x00078268 in AP_TCP_Connection::subscribe (this=0x19c3a0, _procedure=0x173cd0) at src/apps/connector/AP_TCP_Connection.cpp:84 #8 0x00069b78 in Access_Point::subscribe (this=0x166728, _type=@0x12fc30, _procedure=0x173cd0) at src/apps/network_element/Access_Point.cpp:184 #9 0x000762e4 in Procedure_Executor::handle_timeout (this=0x139ee0, _time=@0xfe407930, _procedure=0x0) at src/apps/executor/Procedure_Executor.cpp:79 #10 0xff2c1940 in ACE_Event_Handler_Handle_Timeout_Upcall<ACE_Recursive_Thread_Mutex>::timeout () from /vob/wibb_test/tools/cots/ACE_5.5/ace/libACE.so.5.5.0 #11 0xff26f2e4 in ACE_TP_Reactor::handle_timer_events () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #12 0xff26f160 in ACE_TP_Reactor::dispatch_i () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #13 0xff26eff8 in ACE_TP_Reactor::handle_events () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #14 0xff254e0c in ACE_Reactor::run_reactor_event_loop () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #15 0x00074b30 in Executor_Reactor::svc (this=0x139f58) at src/apps/executor/Executor_Reactor.cpp:22 #16 0xff2668dc in ACE_Task_Base::svc_run () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #17 0xff266cb0 in ACE_Thread_Adapter::invoke_i () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #18 0xff266c1c in ACE_Thread_Adapter::invoke () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #19 0xff216d50 in ace_thread_adapter () at /mot/proj/ivtools/ppatel1/ACE_wrappers/ace/String_Base.inl:32 #20 0xfe8db730 in _thread_start () from /usr/lib/libthread.so.1 #21 0xfe8db730 in _thread_start () from /usr/lib/libthread.so.1 Previous frame identical to this frame (corrupt stack?) (gdb) 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

[BGL] "undirected" edges in a directed graph
by Fernando Cacciola 10 May '06

10 May '06

Hi people, I'm interfacing an algorithm to a data structure via the BGL (that is, I'm presenting the DS as a BGL graph along with various property maps) My data structure is the so-called Halfedge Data Structure (HDS) used in geometric modeling. If the faces of the HDS are not considered, a HDS is a form of Planar Directed Graph (PDG) with the particularity that for any two adjacent vertices p and q, there is an edge from p to q and an opposite edge from q to p. Obtaining the "opposite" edge of any edge is O(1) The structure is called HalfedgeDS because there is always a pair of "Joint Opposite Directed Edges", called halfedges, between p and q : p->q and q->p. Any HDS can be mapped as a BGL graph by simply specializing graph_traits and the global functions accordingly. It just needs as an extension an "opposite_edge" operation. With the "opposite_edge" extension this works like a charm, but there is still one small thing that is natural in the HDS that I'm not sure how to best map to the BGL: Since between any two adjacent vertices p and q there are exactly 2 joint opposite directed edges (that is, two halfedges): p->q and q->p, there is always a very well defined UNDIRECTED view of the HDS: simply considering an arbitraty one of each of the two joint opposite directed edges between any two adjacent vertices. Any edge here (which is a directed edge) can be used an "undirected" edge due to the availability of the opposite_edge() operation. There is at least one operation that needs such an undirected view of the HDS: iterate (not traverse but iterate) all "edges" of the HDS (not "halfedges"). This is of course possible with an ordinary dgraph but much more expensive as it requires the algorithm to filter out halfedges whose opposite was already iterated. Typical instances of a HDS store opposite halfedges pairwise, thus, iterating over all halfedges but stepping 2 at a time, iterates over "undirected edges" very efficienty. This requires a special iterator that is different from the halfedge iterator (and is tyipically provided by HDS models). >From a concept POV I would say that a HDS is a new BGL graph concept. It would call it a "JODE" Graph instead of a "HDS" Graph becasue in the HDS jargon an "edge" is a pair of "halfedges" while in the BGL an "edge" is the actual edge (a directed edge in this case). Such a JODE Graph concept would include the "opposite_edge" operation and the definition of "undirected_edge_iterator", which would iterate over 1 out of the 2 opposite halfedges (Joint Opposite Directed Edges), along with the "undirected_edges" accesor. So far so good... nut I have a problem: where do I put the "undirected_edge_iterator" type?? AFAICT I cannot add an additional type to graph_traits, right? Is subclassing graph_traits a good alternative? Or is there a better way? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/

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, I delete procedure in only two places. And as follows in handle_timeout and handle methods. And I grepped my trace output and handle_timeout never called. So all deletion will be only in one place called "handle" method of that procedure itself. I am going to try it out the changes you mentioned. This is just to let you know how I create and delete procedure objects. Thanks Priyank // PROCEDURE and PROCEDURE DELETER #include "../../procedure/Sample_Procedure.h" int Sample_Procedure::ID = 1000; Sample_Procedure::Sample_Procedure (Access_Point * _ap, int _recv_timer): ap_(_ap), state_(Procedure_State_Enum::INITIAL), type_(Procedure_Type_Enum::SAMPLE_TYPE), recv_timer_(5), recv_timer_handler_(new Procedure_Timer_Handler(recv_timer_)) { LD_TRACE("Sample_Procedure::Sample_Procedure"); id_ = ++Sample_Procedure::ID; } int Sample_Procedure::start() { LD_TRACE("Sample_Procedure::start"); // Create fake message to send char data[4]; memcpy(data, &id_, 4); boost::scoped_ptr<ACE_Message_Block> mb(new ACE_Message_Block(4, ACE_Message_Block::MB_DATA, 0, data)); mb->wr_ptr(4); // end creating fake message // schedule timer for incoming message recv_timer_handler_->schedule(this); // start thread that sends out message after certain interval // send link continuity status request Connection * ap_tcp = (Connection*) ap_->connection(Connection_Type_Enum::AP_TCP); if (ap_tcp) { if (ap_tcp->send(mb) != 0) { ACE_ERROR ((LD_ERROR, "%N:%l Error in sending data.\n")); return -1; } ACE_DEBUG((LM_INFO, "SENT=> P_ID: %d ", id_)); ACE_HEX_DUMP((LM_INFO, data, 4)); } } void Sample_Procedure::handle_timeout() { LD_TRACE("Sample_Procedure::handle_timeout"); // update statistic for failed procedure // REALLY IMPORTANT // MAKE SURE TO DO FOLLOWING // remove this object from connection/s pool // cancel receive handler // delete this object delete this; } int Sample_Procedure::handle(boost::shared_ptr<ACE_Message_Block> _msg_block) { LD_TRACE("Sample_Procedure::handle"); // Log data first ACE_DEBUG((LM_INFO, "RECV<= P_ID: %d ", id_)); ACE_HEX_DUMP((LM_INFO, _msg_block->rd_ptr(), 4)); // update statistic for passed procedure // REALLY IMPORTANT // MAKE SURE TO DO FOLLOWING // remove this object from connection/s pool ap_->unsubscribe(Connection_Type_Enum::AP_TCP, this); // cancel receive timer handler recv_timer_handler_->cancel(); // delete this object. Executor will not delete this object since it will not // go out of the scope untill it's total execution duration finishes, So // delete the procedure as soon as it is done executing to release memory // Also, receive timer handler will be deleted once this object gets deleted // so do not delete that explicitly ACE_DEBUG((LM_DEBUG, "DELETING PROCEDURE: %d\n", this->id())); delete this; } // PROCECURE GENERATOR #include "../include/Procedure_Executor.h" #include "../include/Duration_Timer_Handler.h" #include "../include/Executor_Reactor.h" Procedure_Executor::Procedure_Executor ( const Procedure_Type_Enum& _type, int _starting_sleep, int _hr, int _min, int _sec, int _iterations, int _interval) : procedure_type_(_type), starting_sleep_(_starting_sleep), hr_(_hr), min_(_min), sec_(_sec), duration_(0), num_iterations_(_iterations), interval_(_interval), duration_timer_handler_(0) { LD_TRACE("Procedure_Executor::Procedure_Executor"); // check assertion to make sure proper data is supplied ACE_ASSERT(Procedure_Type_Enum::locate(_type) == true); ACE_ASSERT(hr_ >= 0); ACE_ASSERT(min_ >= 0); ACE_ASSERT(sec_ >= 0); ACE_ASSERT(num_iterations_ > 0); ACE_ASSERT(interval_ > 0); // convert this duration in second duration_ += (60*60*hr_); duration_ += (60*min_); duration_ += sec_; ACE_DEBUG((LM_DEBUG, "%N:%l Duration to run this procedure: %d seconds.\n", duration_)); // convert this duration in millisecond unsigned long milli_sec = interval_ * 1000; // find out sleep time (interval time divided by number of iterations) sleep_ = (unsigned long) (milli_sec / num_iterations_); ACE_DEBUG((LM_DEBUG, "%N:%l Procedure %s will run every %d milliseconds.\n", _type.to_string().c_str(), sleep_)); // create new reactor reactor_.reset(new Executor_Reactor()); // create duration timer handler duration_timer_handler_.reset(new Duration_Timer_Handler(duration_)); } int Procedure_Executor::start() { LD_TRACE("Procedure_Executor::start"); // sleep for starting period time if (starting_sleep_ != 0) { ACE_OS::sleep(starting_sleep_); } // TODO: Might require some change to use high resolution timer stopwatch and // based on that value we might have to sleep more (ofcourse less is not possible.) // start up the reactor reactor_->activate(); // We have registered it recursively so that every time sleep_ will expire, // handle_time of this method will be called ACE_Time_Value * atv1 = new ACE_Time_Value(0, sleep_ * 1000); reactor_->get_ace_reactor().schedule_timer(this, 0, *atv1, *atv1); // start time for duration also, and pass this pointer to that object, that object // should call back stop() method of this class one duration is expires and we will stop // running this procedure duration_timer_handler_->schedule(this, &(reactor_->get_ace_reactor())); // return success return 0; } Procedure_Executor::~Procedure_Executor() { LD_TRACE("Procedure_Executor::~Procedure_Executor"); } int Procedure_Executor::handle_timeout(const ACE_Time_Value &_time, const void * _procedure) { LD_TRACE("Procedure_Executor::handle_timeout"); // select access point Access_Point * ap = (Access_Point*) (Loader_Config::getInstance()->get_aps()->next()); if (ap == 0) { Loader_Config::getInstance()->get_aps()->reset(); ap = (Access_Point*) (Loader_Config::getInstance()->get_aps()->next()); } // create procedure based on procedure type specified if (procedure_type_ == Procedure_Type_Enum::SAMPLE_TYPE) { // create procedure Sample_Procedure * procedure = new Sample_Procedure(ap, 5); // subscribe to related connections ap->subscribe(Connection_Type_Enum::AP_TCP, procedure); // call start of that procedure procedure->start(); } // return success, this will keep this handler in register for further calls return 0; } int Procedure_Executor::stop() { LD_TRACE("Procedure_Executor::stop"); // stop the reactor reactor_->stop(); // remove duration handler from reactor reactor_->get_ace_reactor().remove_handler(duration_timer_handler_.get(), ACE_Event_Handler::TIMER_MASK); // remove this from reactor reactor_->get_ace_reactor().remove_handler(this, ACE_Event_Handler::TIMER_MASK); // return success return 0; } -----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

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