Re: [Boost-users] [multi_index] Core dump in multi-index library !!

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-05-10 13:04:37

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