Re: [Bayes++] Crash on destruction of SIR_scheme

[yon <yo...@ci...>]

Hello,

Just to follow up on the problem I asked about:

-- The program does not crash, rather it hangs.

-- When I interrupt the hang by pausing in the debugger, the stack =20
trace looks similar to that noted below, but slightly different:

#0  std::_Destroy<unsigned long*, std::allocator<unsigned long> > =20
(__first=3D0x856ef238, __last=3D0x82, __alloc=3D@0xbfffe4ef) at /usr/=20
include/c++/4.0.0/bits/stl_construct.h:173
#1  0x315c2895 in std::vector<unsigned long, std::allocator<unsigned =20
long> >::~vector (this=3D0x30852844) at /usr/include/c++/4.0.0/bits/=20
stl_vector.h:273
#2  0x315c2d72 in Bayesian_filter::SIR_scheme::~SIR_scheme =20
(this=3D0x30852820, __vtt_parm=3D0x316057a4) at /Developer/YV-dev/=20
dcppf-0.91/../Bayes++/BayesFilter/SIRFlt.hpp:179
#3  0x315c4599 in SIR_scheme_ext::~SIR_scheme_ext (this=3D0x30852820) =20=

at /Developer/YV-dev/dcppf-0.91/SIR_scheme_ext.h:21

it is always stuck in std::_Destroy which is called in response to =20
destroying the unsigned long vector noted above in this section of =20
~vector:

       ~vector()
       { std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
		      this->get_allocator());
       }

I don't know where the unsigned long vector being destroyed here =20
resides.


The arguments to std::_Destroy in this call look like the problem to =20
me.  In the relevant section of std::_Destroy,

   template<typename _ForwardIterator, typename _Allocator>
     void
     _Destroy(_ForwardIterator __first, _ForwardIterator __last,
	     _Allocator __alloc)
     {
       for (; __first !=3D __last; ++__first)
	__alloc.destroy(&*__first);
     }

The address __last is always the address with decimal value 130 while =20=

__first is typically some large number orders of magnitude higher.  =20
130 represents the number of samples (particles) in the filter, and =20
presumably is the length of the vector here.

It looks to me like this->_M_impl._M_finish  (which becomes __last) =20
is not set correctly in the std::vector.  If I understand correctly, =20
this vector has somehow acquired a pointer to its last element which =20
has an address that is errantly set equal to its length.

Since I am not making pointer manipulations with the ublas vectors, I =20=

am not sure how I could have caused this in my own code, and in any =20
case, I can't find the vector that is responsible in the Bayes++ code =20=

or anywhere else.


Thanks for any advice,
Yon


On Sep 5, 2007, at 6:00 PM, yon wrote:

> Hello,
>
> I'm a bit stuck with a bug afflicting my program that uses Bayes++.
>
> I am consistently crashing when the destructor for SIR_scheme is =20
> called by a class I inherited from it.  The trace below implicates =20
> the destructor for an unsigned long vector, but there is no member =20
> of this type in SIR_scheme (nor in the other classes related to it, =20=

> as far as I can tell).
>
> Can anyone offer me advice as to how to locate the cause, or advise =20=

> as to whether this is my code or a problem in one of the libraries?
>
> Thank you,
> Yon
>
>
> #0  0x315c2539 in __gnu_cxx::new_allocator<unsigned long>::destroy =20
> (this=3D0xae6ce8c4, __p=3D0x82) at /usr/include/c++/4.0.0/ext/=20
> new_allocator.h:107
> #1  0x315c2895 in std::vector<unsigned long, =20
> std::allocator<unsigned long> >::~vector (this=3D0x30852844) at /usr/=20=

> include/c++/4.0.0/bits/stl_vector.h:273
> #2  0x315c2d72 in Bayesian_filter::SIR_scheme::~SIR_scheme =20
> (this=3D0x30852820, __vtt_parm=3D0x316057a4) at /Developer/YV-dev/=20
> dcppf-0.91/../Bayes++/BayesFilter/SIRFlt.hpp:179
> #3  0x315c4599 in SIR_scheme_ext::~SIR_scheme_ext (this=3D0x30852820) =20=

> at /Developer/YV-dev/dcppf-0.91/SIR_scheme_ext.h:21
> .
> .
>
>
> __________________________________
> Yon Visell
>
> Centre for Intelligent Machines, McGill University
> http://cim.mcgill.ca/~yon
>
> CIRMMT, Schulich School of Music, McGill University
> http://www.music.mcgill.ca/cirmmt
>
> University of Applied Sciences & Arts Z=FCrich
> CLOSED: Closing the loop of sound evaluation and design
> http://closed.ircam.fr
>
> Zero-Th Association, Pula, Croatia
> http://www.zero-th.org
>
> Tel +1 514 967 1648
> Fax +1 415 520 0193
>
>
>



__________________________________
Yon Visell

Centre for Intelligent Machines, McGill University
http://cim.mcgill.ca/~yon

CIRMMT, Schulich School of Music, McGill University
http://www.music.mcgill.ca/cirmmt

University of Applied Sciences & Arts Z=FCrich
CLOSED: Closing the loop of sound evaluation and design
http://closed.ircam.fr

Zero-Th Association, Pula, Croatia
http://www.zero-th.org

Tel +1 514 967 1648
Fax +1 415 520 0193