README_PACKAGERS
Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc’d
at 0x4004318C: __builtin_vec_new (vg_clientfuncs.c:152)
by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)
This tells you that some memory allocated with new[] was freed with
free().
Mismatched free() / delete / delete []
at 0x40043249: (inside vgpreload_memcheck.so)
by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)
by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)
by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)
Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc’d
at 0x4004318C: (inside vgpreload_memcheck.so)
by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)
This isn’t so helpful.
Although you can tell there is a mismatch,
the names of the allocating and deallocating functions are no longer
visible.
The same kind of thing occurs in various other messages
from valgrind.
-- Don’t strip symbols from lib/valgrind/* in the installation tree.
Doing so will likely cause problems.
Removing the line number info is
probably OK (at least for some of the files in that directory), although
that has not been tested by the Valgrind developers.
-- Please test the final installation works by running it on something
huge.
I suggest checking that it can start and exit successfully
both Firefox and OpenOffice.org.
I use these as test programs, and I
know they fairly thoroughly exercise Valgrind.
The command lines to use
are:
valgrind -v --trace-children=yes firefox
valgrind -v --trace-children=yes soffice
If you find any more hints/tips for packaging, please report
it as a bugreport. See http://www.valgrind.org for details.
87