On Tue, 24 Jul 2001, Andre Poenitz wrote:
> > Maybe it is a good starting point to have a look MathArray::MathArray...?
>
> The constructor is ok. It's probably one of the MathArray::insert() thingys
> that overwrite one or two of the embedded MathInset *...
>
> I cannot really read this output, maybe you could give a hint why you think
> that the constructort is the problem?
>
> > ******************
> >
> > MLK: 10800 bytes leaked in 3 blocks
> > This memory was allocated from:
> > malloc [rtlib.o]
> > __malloc_alloc_template<0>::allocate(unsigned int)
> > [stl_alloc.h:157]
> > allocate__t24__default_alloc_template2b0i0Ui
> > [stl_alloc.h:407]
> >
> > allocate__t12simple_alloc2Z10MathXArrayZt24__default_alloc_template2b0i0Ui
> > [stl_alloc.h:228]
> >
> > _M_allocate__t18_Vector_alloc_base3Z10MathXArrayZt9allocator1Z10MathXArrayb1Ui
> > [stl_vector.h:93]
> >
> >
>_Vector_base<MathXArray,allocator<MathXArray>>::_Vector_base<MathXArray,allocator<MathXArray>>(unsigned
> > int,const allocator<MathXArray>&) [stl_vector.h:110]
> >
> >
>vector<MathXArray,allocator<MathXArray>>::vector<MathXArray,allocator<MathXArray>>(const
> > vector<MathXArray,allocator<MathXArray>>&) [stl_vector.h:234]
> > MathInset::MathInset(const MathInset&) [math_inset.h:232]
> > MathGridInset::MathGridInset(const MathGridInset&)
> > [math_gridinset.h:129]
> > MathArrayInset::MathArrayInset(const MathArrayInset&)
> > [math_arrayinset.h:20]
Hi Andre,
here comes a short explanation on how to interpret Purify's output:
1. You should interpret the stack of functions just like any other
backtrace in a debugger, i.e. each function has called the function
above.
2. All functions that were defined in "stl_*" are certainly not the
source of the memory leak as we can (should) assume the STL works
correctly.
3. MathInset::MathInset is a constructor that is implicitly defined by
the C++ compiler (at least I could not find a definition). So
it just copies the content of one object to another. Obviously, this
cannot cause a memory leak, too (at most a memory access problem
when dealing with pointers).
4. The same applies to MathGridInset::MathGridInset.
In other words: You can start your investigations from the first
non-trivial function. If you think this one is correct (and in the case
of a constructor you should check, of course, whether the destructor is
implemented correctly as well), go down to the next.
Michael
--
======================================================================
Michael Schmitt phone: +49 451 500 3725
Institute for Telematics secretary: +49 451 500 3721
Medical University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: [EMAIL PROTECTED]
D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de
======================================================================