I looked at this bug and ran doc++ under valgrind on i386, and it found
a problem:
==24836== Mismatched free() / delete / delete []
==24836== at 0x1B904B04: free (vg_replace_malloc.c:152)
==24836== by 0x80813A6: TOClist::~TOClist()
(in /home/liw/Debian-bug-fixing/doc++/doc++-3.4.10/src/doc++)
==24836== by 0x80836D0: writeTOC(_IO_FILE*)
(in /home/liw/Debian-bug-fixing/doc++/doc++-3.4.10/src/doc++)
==24836== by 0x8088077: doHTML(char const*, Entry*)
(in /home/liw/Debian-bug-fixing/doc++/doc++-3.4.10/src/doc++)
==24836== by 0x80900ED: main (in /home/liw/Debian-bug-fixing/doc
++/doc++-3.4.10/src/doc++)
==24836== Address 0x1BD79E30 is 0 bytes inside a block of size 68
alloc'd
==24836== at 0x1B904727: operator new(unsigned)
(vg_replace_malloc.c:132)
==24836== by 0x8083406: writeTOCRec(TOClist&, _IO_FILE*, Entry*, int,
int&) (in /home/liw/Debian-bug-fixing/doc++/doc++-3.4.10/src/doc++)
==24836== by 0x80834F2: writeTOCRec(TOClist&, _IO_FILE*, Entry*, int,
int&) (in /home/liw/Debian-bug-fixing/doc++/doc++-3.4.10/src/doc++)
==24836== by 0x8083605: writeTOC(_IO_FILE*)
(in /home/liw/Debian-bug-fixing/doc++/doc++-3.4.10/src/doc++)
==24836== by 0x8088077: doHTML(char const*, Entry*)
(in /home/liw/Debian-bug-fixing/doc++/doc++-3.4.10/src/doc++)
==24836== by 0x80900ED: main (in /home/liw/Debian-bug-fixing/doc
++/doc++-3.4.10/src/doc++)
Commenting out the body of ~TOClist silences valgrind:
TOClist::~TOClist()
{
#if 0
int i;
for(i = 0; i < list.size(); i++)
if(list[i].tl)
free(list[i].tl);
#endif
}
I don't know, however, if that is anything more than a trivial
workaround. It probably introduces memory leaks, and whether it is
possible to live with them or not is something I can't say, since I
understand neither the program nor C++.
This change does not make the segfault on m68k go away, either.
(unstable)[EMAIL PROTECTED]:~/doc++-3.4.10$ (cd doc/manual && gdb ../../src/doc
++) GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "m68k-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) run -d html ./doc.dxx
Starting program: /home/lars/doc++-3.4.10/src/doc++ -d html ./doc.dxx
Program received signal SIGSEGV, Segmentation fault.
0xc01683c4 in mallopt () from /lib/libc.so.6
(gdb) bt
#0 0xc01683c4 in mallopt () from /lib/libc.so.6
#1 0xc0167688 in malloc () from /lib/libc.so.6
#2 0x8000c9fc in McDArray<char>::McDArray ()
#3 0x8000b584 in McString::McString ()
#4 0x80042392 in writeTOCentry ()
#5 0x8004259e in writeTOCentry ()
#6 0x80040438 in HIERlist::write ()
#7 0x80040da6 in writeHIER ()
#8 0x80048286 in doHTML ()
#9 0x800511a4 in main ()
(gdb) The program is running. Exit anyway? (y or n) y
I didn't get gdb to show source file names and line numbers, but
hopefully that is helpful at least.
My guess is that something, somewhere, screws up malloc's data
structures (double frees, random pointers, that sort of thing) and that
is why it crashes inside mallopt.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
