Ok..let me try that out... Thanks a lot, Priyank -----Original Message----- From: boost-users-bounces@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@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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users