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

Re: [Boost-users] [multi_index] thread safety
by Conway Allen 11 May '06

11 May '06

Regarding thread safety, if threads are concurrently reading, inserting, and erasing entries in a multi-index container do you have to lockguard all of these operations or can you get away with just lockguarding the inserts and the deletes? Thanks, Allen. -----Message d'origine----- De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de JOAQUIN LOPEZ MU?Z Envoyé : mercredi 10 mai 2006 23:36 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] [multi_index] Core dump in multi-index library !! 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. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] Template instantiation problem
by Gottlob Frege 11 May '06

11 May '06

Date: Wed, 10 May 2006 15:30:08 -0700 > From: Rush Manbert <rush(a)manbert.com> > Subject: [Boost-users] Template instantiation problem > To: boost-users(a)lists.boost.org > Message-ID: <44626970.4070704(a)manbert.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I have a template class that is designed to contain built in types or > std::string types. I always need to be able to cast an instance of the > class as a std::string, and I also need to be able to cast it as the > parameter type with which it was instantiated. > > In my class definition, I have defined two cast operators, like so: > (Extraneous stuff omitted) > > template<typename T> > class MyDataObject : public MyDataObjectBase > { > > // Cast as std::string > inline operator const std::string & () > { > ...some code here > } > > // Cast as T > inline operator const T & () > { > ...some code here > } > } > > The original code was written on a Mac and compiled with Gnu, which did > not complain. even when I did this: > > class MyStringObjectClass : public MyDataObject<std::string> > { > } > > Now, however, I have moved the code to Windows, and the Visual Studio > compiler complains about the second cast operator when I define > MyStringObjectClass. > > I thought that if I could conditionally define the cast as T operator > (or the cast as std::string) I would be okay, but that means testing > against the value of T with the preprocessor. I don't see how to do > that, but I know that some of you folks are really good at bending the > preprocessor to your will. > > Can anyone show me a way out of this predicament? > > Thanks, > Rush Take a look at enable_if. ie boost::mpl::enable_if I think. Also is_same. With those you can check if your T is_same as std::string, and enable (or disable) your operators accordingly. Tony.

1 0

Template instantiation problem
by Rush Manbert 11 May '06

11 May '06

I have a template class that is designed to contain built in types or std::string types. I always need to be able to cast an instance of the class as a std::string, and I also need to be able to cast it as the parameter type with which it was instantiated. In my class definition, I have defined two cast operators, like so: (Extraneous stuff omitted) template<typename T> class MyDataObject : public MyDataObjectBase { // Cast as std::string inline operator const std::string & () { ...some code here } // Cast as T inline operator const T & () { ...some code here } } The original code was written on a Mac and compiled with Gnu, which did not complain. even when I did this: class MyStringObjectClass : public MyDataObject<std::string> { } Now, however, I have moved the code to Windows, and the Visual Studio compiler complains about the second cast operator when I define MyStringObjectClass. I thought that if I could conditionally define the cast as T operator (or the cast as std::string) I would be okay, but that means testing against the value of T with the preprocessor. I don't see how to do that, but I know that some of you folks are really good at bending the preprocessor to your will. Can anyone show me a way out of this predicament? Thanks, Rush

3 2

Compiling boost on Sol 5.2 compiler
by Vadivelu Rahuraman 11 May '06

11 May '06

Hi, I am trying to use boost with Solaris 5.2 compiler. I am getting a compiler error as a result of the macor BOOST_AUX_NTTP_DECL not being defined anywhere. I would appreciate it very much if anyone could point me how I can get past this stage. Thanks, Rahu

1 0

[Wave] effect of allocation of data structures on copying data structures
by Andreas Sæbjørnsen 10 May '06

10 May '06

I need some advice regarding how I should copy the boost data structures I get from 'advanced_preprocessing_hooks.h'. The task at hand is to copy some of the data structures from Wave and store it separate form the memory Wave allocates so that after the Wave preprocessing step has finished all it's memory can be freed. Example: e.g making a copy of the 'std::vector<std::list<PreprocessingInfo::token_type,boost::fast_pool_allocator<PreprocessingInfo::token_type> > >' representing the arguments in the expansion of a macro in the function 'expanding_function_like_macro'. Syntactically it would be gre at to be able to make a copy using the operator=, but as far as I can see this is only possible if I am also using the fast_pool_allocator. If I use the fast_pool_allocator I am afraid that my copies will be put into the memory pool allocated by Wave and therefore that memory cannot be safely freed. Is this corect? .

2 1

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