|
From: Leonard m. <spa...@ya...> - 2003-06-09 22:05:15
|
Pulled CVS today and I'm getting 10s of thousands of Mismatched free errors that aren't mismatched, a known issue reported earlier in the archives. What version of gcc are the valgrind developers running with? I'll just rebuild my app tree with that and be done with it. Thanks, Randall P.S. BTW, thanks for the SSE patches and improved thread support! I'm thrilled I can run some apps through valgrind now that I couldn't before. __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2003-06-10 07:28:57
|
On Mon, 9 Jun 2003, Leonard mckinley wrote: > Pulled CVS today and I'm getting 10s of thousands of Mismatched free > errors that aren't mismatched, a known issue reported earlier in the > archives. > > What version of gcc are the valgrind developers running with? I'll > just rebuild my app tree with that and be done with it. I use: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) Ancient history, eh? I recently tried 3.2.3 but the compile times were noticeably slower so I switched back to 2.96. N |
|
From: Melchior F. <mf...@kd...> - 2003-06-10 09:16:31
|
* Leonard mckinley -- Tuesday 10 June 2003 00:05:
> Pulled CVS today and I'm getting 10s of thousands of Mismatched free
> errors that aren't mismatched, a known issue reported earlier in the
> archives.
I can confirm that cvs/head gives hundreds of bogus error messages
about mismatched allocation. I only checked one of them and saw that
the concerned code creates an automatic variable of a c++ object.
valgrind obviously complains when the auto var is to be destroyed
at function end. The bug was introduced with "vg_replace_malloc.c"
revision 1.7. (1.6 did still work.)
Example error message from debugging FlightGear/gcc 3.2/Linux 2.4.21-pre6:
==10706== Mismatched free() / delete / delete []
==10706== at 0x400263EC: __builtin_vec_delete (vg_replace_malloc.c:252)
==10706== by 0x4002640C: operator delete[](void*) (vg_replace_malloc.c:261)
==10706== by 0x8491E79: ulRTTITypeinfo::ulRTTITypeinfo(char const*, ulRTTITypeinfo const**, void* (*)(int, void*), void* (*)()) (ulRTTI.cxx:50)
==10706== Address 0x42B4EA2C is 0 bytes inside a block of size 4 alloc'd
==10706== at 0x40026020: malloc (vg_replace_malloc.c:153)
==10706== by 0x4033789D: operator new(unsigned) (in /usr/lib/libGLU.so.1.3)
==10706== by 0x403379FE: operator new[](unsigned) (in /usr/lib/libGLU.so.1.3)
==10706== by 0x8491E34: ulRTTITypeinfo::ulRTTITypeinfo(char const*, ulRTTITypeinfo const**, void* (*)(int, void*), void* (*)()) (ulRTTI.cxx:67)
And then: line 123 in configure.in from cvs/head causes the
following error when running ./autogen.sh:
running: autoconf
configure.in:123: error: possibly undefined macro: AC_PROG_EGREP
error: while running 'autoconf'
Commenting this check out makes ./autogen.sh work. The funny thing
is, that if I run autoconf manually, then I do neither get a complaint
about AC_PROG_EGREP, nor an error return value. (WTF??)
m.
PS: I didn't mean to be ungrateful when I complained about my joystick
patch being ignored for a month. I =am= grateful for that wonderful
tool and all your work on it! :-)
|
|
From: Nicholas N. <nj...@ca...> - 2003-06-12 10:28:01
|
On Tue, 10 Jun 2003, Melchior FRANZ wrote: > I can confirm that cvs/head gives hundreds of bogus error messages > about mismatched allocation. I only checked one of them and saw that > the concerned code creates an automatic variable of a c++ object. > valgrind obviously complains when the auto var is to be destroyed > at function end. The bug was introduced with "vg_replace_malloc.c" > revision 1.7. (1.6 did still work.) We've rolled back to 1.6 in CVS. The change was intended to fix another problem, but ended up breaking more things than it fixed, on some machines. Thanks for the feedback. N |
|
From: Leonard m. <spa...@ya...> - 2003-06-10 11:04:49
|
> Pulled CVS today and I'm getting 10s of thousands of Mismatched free
> errors that aren't mismatched, a known issue reported earlier in the
> archives.
Thanks for the replies. I'll try gcc 2.96.
Here's more info for those working on the CVS head. This program:
int main()
{
int *block, *block_list;
block = new int;
block_list = new int[ 10 ];
delete block;
delete [] block_list;
}
generates these errors:
==29084== Mismatched free() / delete / delete []
==29084== at 0x40026350: __builtin_delete (vg_replace_malloc.c:233)
==29084== by 0x40026370: operator delete(void*)
(vg_replace_malloc.c:242)
==29084== by 0x8048506: main (tst.C:7)
==29084== by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
==29084== Address 0x411190D4 is 0 bytes inside a block of size 4
alloc'd
==29084== at 0x40026020: malloc (vg_replace_malloc.c:153)
==29084== by 0x402B194D: operator new(unsigned) (in
/usr/lib/libstdc++.so.5.0.0)
==29084== by 0x80484E5: main (tst.C:5)
==29084== by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
==29084==
==29084== Mismatched free() / delete / delete []
==29084== at 0x400263EC: __builtin_vec_delete
(vg_replace_malloc.c:252)
==29084== by 0x4002640C: operator delete[](void*)
(vg_replace_malloc.c:261)
==29084== by 0x804851A: main (tst.C:8)
==29084== by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
==29084== Address 0x41119108 is 0 bytes inside a block of size 40
alloc'd
==29084== at 0x40026020: malloc (vg_replace_malloc.c:153)
==29084== by 0x402B194D: operator new(unsigned) (in
/usr/lib/libstdc++.so.5.0.0)
==29084== by 0x402B1AAE: operator new[](unsigned) (in
/usr/lib/libstdc++.so.5.0.0)
==29084== by 0x80484F5: main (tst.C:6)
using valgrind from CVS yesterday with gcc 3.2 and glibc 2.2.5 (SuSE
8.1).
Randall
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
|