|
From: Salvador E. T. <sal...@in...> - 2004-05-10 14:39:17
|
Valgrind version: 2.1.1 and 2.0.0 (can=B4t test CVS because it needs newe=
r=20
autotools)
Brief description: Valgrind hooks __builtin_delete but fails to hook=20
__builtin_new resulting in tons of wrong reports about "Mismatched=20
free() / delete / delete []".
System: Debian GNU/Linux Woody, gcc 2.95.4 *important*: libgcc is an=20
static library for Woody. GNU libc 2.2.5.
More info:
I get things like it:
=3D=3D32691=3D=3D Mismatched free() / delete / delete=20
[] =
=20
=3D=3D32691=3D=3D at 0x3C01A8DB: __builtin_delete=20
(vg_replace_malloc.c:128) =
=20
=3D=3D32691=3D=3D by 0x3C0A2319: TStringCollection::~TStringCollection=
(void)=20
(../classes/tstringc.cc:65) =20
=3D=3D32691=3D=3D by 0x80BB591: LoadTVMenuAndStatus(char *)=20
(../../tvision/include/tv/object.h:45) =20
=3D=3D32691=3D=3D by 0x80BB650: LoadMenuAndStatus(char *, int)=20
(../setedit/menuload.cc:1059) =20
=3D=3D32691=3D=3D Address 0x3C65C06C is 0 bytes inside a block of size 4=
4=20
alloc'd =20
=3D=3D32691=3D=3D at 0x3C01A2F5: malloc=20
(vg_replace_malloc.c:105) =
=20
=3D=3D32691=3D=3D by 0x80FF8F8: __builtin_new (in=20
/usr/src/setedit/makes/editor.exe) =
=20
=3D=3D32691=3D=3D by 0x80BB277: LoadTVMenuAndStatus(char *)=20
(../setedit/menuload.cc:963) =20
=3D=3D32691=3D=3D by 0x80BB650: LoadMenuAndStatus(char *, int)=20
(../setedit/menuload.cc:1059) =20
=3D=3D32691=3D=3D
As you can see valgrind thinks that I allocated with malloc and that I=B4=
m=20
deallocating with delete.
Something similar happends with new[]/delete[]:
=3D=3D32691=3D=3D Mismatched free() / delete / delete=20
[] =
=20
=3D=3D32691=3D=3D at 0x3C01A83F: free=20
(vg_replace_malloc.c:127) =
=20
=3D=3D32691=3D=3D by 0x80FFA43: __builtin_vec_delete (in=20
/usr/src/setedit/makes/editor.exe) =20
=3D=3D32691=3D=3D by 0x80803A3: TSetEditorApp::SetTitle(char const *, =
char=20
const *) (../setedit/editmain.cc:437) =20
=3D=3D32691=3D=3D by 0x8085154: main=20
(../setedit/editmain.cc:2868) =
=20
=3D=3D32691=3D=3D Address 0x3C66C1C4 is 0 bytes inside a block of size 2=
4=20
alloc'd =20
=3D=3D32691=3D=3D at 0x3C01A602: __builtin_vec_new=20
(vg_replace_malloc.c:112) =
=20
=3D=3D32691=3D=3D by 0x3C0AA491: TVIntl::getTextNew(char const *, bool=
)=20
(../classes/tvintl.cc:153) =20
=3D=3D32691=3D=3D by 0x80802EA: TSetEditorApp::SetTitle(char const *, =
char=20
const *) (../setedit/editmain.cc:421) =20
=3D=3D32691=3D=3D by 0x8085154: main (../setedit/editmain.cc:2868) =
ith=20
new[]/delete[]:
I=B4m confused about the fact that valgrind hooks some functions and fail=
s=20
with others.
I generated a map of my application (/usr/src/setedit/makes/editor.exe)=20
and the functions:
0x80FFA43: __builtin_vec_delete
0x80FF8F8: __builtin_new
Are statically linked, but the same is for __builtin_vec_new and=20
__builtin_delete.
I added some "printfs" to coregrind/vg_replace_malloc.c to see what is=20
trying to hook, I added this to the loop in init:
VALGRIND_INTERNAL_PRINTF("--> Reemplazando %s %p\n",
replacements[i].libname,
replacements[i].func);
Y get:
=3D=3D18807=3D=3D --> Reemplazando __builtin_new 0x3C01A314
=3D=3D18807=3D=3D --> Reemplazando __builtin_vec_new 0x3C01A560
=3D=3D18807=3D=3D --> Reemplazando __builtin_delete 0x3C01A848
=3D=3D18807=3D=3D --> Reemplazando __builtin_vec_delete 0x3C01A980
So valgrind is trying to hook all of them.
One thing that could be related to it is that when I compile=20
vf_replace_malloc.c I get warnings like this:
vg_replace_malloc.c:105: warning: `visibility' attribute directive ignore=
d
I consulted the gcc docs and "visibility" isn=B4t valid for gcc 2.95.
So I think that:
1) The ALIAS macro should be declared conditionaly checking gcc version.
2) It could have some relation.
SET
--=20
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: se...@co... se...@ie...=20
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
|
|
From: Nicholas N. <nj...@ca...> - 2004-05-10 14:51:38
|
On Mon, 10 May 2004, Salvador Eduardo Tropea wrote: > vg_replace_malloc.c:105: warning: `visibility' attribute directive ignore= d > > I consulted the gcc docs and "visibility" isn=B4t valid for gcc 2.95. > So I think that: > > 1) The ALIAS macro should be declared conditionaly checking gcc version. > 2) It could have some relation. What happens if you take out the ALIAS macro? N |
|
From: Salvador E. T. <sal...@in...> - 2004-05-10 15:47:25
|
Nicholas Nethercote wrote: >On Mon, 10 May 2004, Salvador Eduardo Tropea wrote: > > =20 > >>vg_replace_malloc.c:105: warning: `visibility' attribute directive igno= red >> >>I consulted the gcc docs and "visibility" isn=B4t valid for gcc 2.95. >>So I think that: >> >>1) The ALIAS macro should be declared conditionaly checking gcc version= =2E >>2) It could have some relation. >> =20 >> > >What happens if you take out the ALIAS macro? > =20 > Same problem. I tried defining ALIAS as a no-op and as just: #define ALIAS(ret, name, args, toname) \ ret name args __attribute__((alias(#toname))) And I get the same problem :-( SET --=20 Salvador Eduardo Tropea (SET). (Electronics Engineer) Visit my home page: http://welcome.to/SetSoft or http://www.geocities.com/SiliconValley/Vista/6552/ Alternative e-mail: se...@co... se...@ie...=20 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013 |
|
From: Sergey V. <vs...@al...> - 2004-05-10 19:01:03
|
On Mon, 10 May 2004 11:39:18 -0300, Salvador Eduardo Tropea wrote: > Valgrind version: 2.1.1 and 2.0.0 (can't test CVS because it needs newer > autotools) > > Brief description: Valgrind hooks __builtin_delete but fails to hook > __builtin_new resulting in tons of wrong reports about "Mismatched > free() / delete / delete []". > > System: Debian GNU/Linux Woody, gcc 2.95.4 *important*: libgcc is an > static library for Woody. GNU libc 2.2.5. > > More info: > I get things like it: > ==32691== Mismatched free() / delete / delete [] > > ==32691== at 0x3C01A8DB: __builtin_delete (vg_replace_malloc.c:128) > > ==32691== by 0x3C0A2319: TStringCollection::~TStringCollection(void) > (../classes/tstringc.cc:65) > ==32691== by 0x80BB591: LoadTVMenuAndStatus(char *) > (../../tvision/include/tv/object.h:45) ==32691== by 0x80BB650: > LoadMenuAndStatus(char *, int) (../setedit/menuload.cc:1059) > ==32691== Address 0x3C65C06C is 0 bytes inside a block of size 44 > alloc'd > ==32691== at 0x3C01A2F5: malloc > (vg_replace_malloc.c:105) > > ==32691== by 0x80FF8F8: __builtin_new (in > /usr/src/setedit/makes/editor.exe) This is the problem. In valgrind-2.1.1 vg_replace_malloc.c:init() hooks calls to functions only in libc.so.6 and libstdc++*. Current CVS uses a different mechanism for this, but it also replaces the functions only in these specific libraries. Is your program linked with shared libstdc++ library? This should happen automatically if g++ (not gcc) is called for linking. |
|
From: Salvador E. T. <sal...@in...> - 2004-05-10 19:38:23
|
Sergey Vlasov wrote:
>>==32691== by 0x80FF8F8: __builtin_new (in
>>/usr/src/setedit/makes/editor.exe)
>>
>>
>
>This is the problem. In valgrind-2.1.1 vg_replace_malloc.c:init() hooks
>calls to functions only in libc.so.6 and libstdc++*. Current CVS uses a
>different mechanism for this, but it also replaces the functions only in
>these specific libraries.
>
>
In this system __builtin_* are from libgcc.a
>Is your program linked with shared libstdc++ library? This should happen
>automatically if g++ (not gcc) is called for linking.
>
>
Yes:
$ ldd /usr/src/setedit/makes/editor.exe
librhtv.so.2.0.3 => /usr/lib/librhtv.so.2.0.3 (0x4001a000)
libdl.so.2 => /lib/libdl.so.2 (0x400e9000)
libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x400ed000)
libaa.so.1 => /usr/lib/libaa.so.1 (0x400fd000)
libz.so.1 => /usr/lib/libz.so.1 (0x40116000)
libpcre.so.3 => /usr/lib/libpcre.so.3 (0x40124000)
libc.so.6 => /lib/libc.so.6 (0x4012d000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x4024a000) <------------ here
libm.so.6 => /lib/libm.so.6 (0x40293000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x402b4000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4038f000)
libgpm.so.1 => /usr/lib/libgpm.so.1 (0x403a3000)
libncurses.so.5 => /lib/libncurses.so.5 (0x403a9000)
libslang.so.1 => /lib/libslang.so.1 (0x403e7000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40448000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40492000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4049a000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x404b1000)
But again: The __builtin_* functions are defined in a static library
(libgcc.a)
What is confusing is that valgrind is hooking half of them ...
SET
--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: se...@co... se...@ie...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
|
|
From: Sergey V. <vs...@al...> - 2004-05-10 20:18:58
|
On Mon, 10 May 2004 16:38:18 -0300, Salvador Eduardo Tropea wrote: > In this system __builtin_* are from libgcc.a libstdc++-libc6.2-2.so.3 might still export them (it does so here, although the symbols are weak so they can be overridden by the program). >>Is your program linked with shared libstdc++ library? This should happen >>automatically if g++ (not gcc) is called for linking. >> >> > Yes: > > $ ldd /usr/src/setedit/makes/editor.exe > librhtv.so.2.0.3 => /usr/lib/librhtv.so.2.0.3 (0x4001a000) And how is this library linked (apply ldd to it)? I have reproduced something similar by linking a (dummy) shared library with gcc -shared (so it would get an internal copy of referenced builtins) and then linking a program against it with g++. If the shared library was linked with g++ -shared, all worked OK - the single copy in libstdc++ was used. > libdl.so.2 => /lib/libdl.so.2 (0x400e9000) > libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x400ed000) > libaa.so.1 => /usr/lib/libaa.so.1 (0x400fd000) > libz.so.1 => /usr/lib/libz.so.1 (0x40116000) > libpcre.so.3 => /usr/lib/libpcre.so.3 (0x40124000) > libc.so.6 => /lib/libc.so.6 (0x4012d000) > libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 > (0x4024a000) <------------ here > libm.so.6 => /lib/libm.so.6 (0x40293000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x402b4000) > libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4038f000) > libgpm.so.1 => /usr/lib/libgpm.so.1 (0x403a3000) > libncurses.so.5 => /lib/libncurses.so.5 (0x403a9000) > libslang.so.1 => /lib/libslang.so.1 (0x403e7000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40448000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40492000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4049a000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x404b1000) > > But again: The __builtin_* functions are defined in a static library > (libgcc.a) > What is confusing is that valgrind is hooking half of them ... > > SET |
|
From: Salvador E. T. <sal...@in...> - 2004-05-10 20:52:03
|
Sergey Vlasov wrote:
>On Mon, 10 May 2004 16:38:18 -0300, Salvador Eduardo Tropea wrote:
>
> =20
>
>>In this system __builtin_* are from libgcc.a
>> =20
>>
>
>libstdc++-libc6.2-2.so.3 might still export them (it does so here,
>although the symbols are weak so they can be overridden by the program).=
> =20
>
Ok. In this case I verified that all the __builtin_* symbols included in =
the binary come from libgcc.a. Here is text from the map file generated=20
by ld:
.text 0x080ff820 0xa0=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opdel.o)
0x080ff820 __builtin_delete
.text 0x080ff8c0 0x150=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opnew.o)
0x080ff8c0 __builtin_new
.text 0x080ffa10 0xa0=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opvdel.o)
0x080ffa10 __builtin_vec_delete
.text 0x080ffab0 0xa0=20
/usr/lib/gcc-lib/i386-linux/2.95.4/libgcc.a(opvnew.o)
0x080ffab0 __builtin_vec_new
>>>Is your program linked with shared libstdc++ library? This should hap=
pen
>>>automatically if g++ (not gcc) is called for linking.
>>>=20
>>>
>>> =20
>>>
>>Yes:
>>
>>$ ldd /usr/src/setedit/makes/editor.exe
>> librhtv.so.2.0.3 =3D> /usr/lib/librhtv.so.2.0.3 (0x4001a000)
>> =20
>>
>
>And how is this library linked (apply ldd to it)?
> =20
>
$ ldd /usr/lib/librhtv.so.2.0.3
libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x400d6000)
libXmu.so.6 =3D> /usr/X11R6/lib/libXmu.so.6 (0x401b0000)
libgpm.so.1 =3D> /usr/lib/libgpm.so.1 (0x401c5000)
libncurses.so.5 =3D> /lib/libncurses.so.5 (0x401cb000)
libstdc++-libc6.2-2.so.3 =3D> /usr/lib/libstdc++-libc6.2-2.so.3=20
(0x40209000)
libm.so.6 =3D> /lib/libm.so.6 (0x40252000)
libc.so.6 =3D> /lib/libc.so.6 (0x40273000)
libXt.so.6 =3D> /usr/X11R6/lib/libXt.so.6 (0x40390000)
libSM.so.6 =3D> /usr/X11R6/lib/libSM.so.6 (0x403da000)
libICE.so.6 =3D> /usr/X11R6/lib/libICE.so.6 (0x403e2000)
libXext.so.6 =3D> /usr/X11R6/lib/libXext.so.6 (0x403f9000)
/lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x80000000)
Tell me if you need more info about the way it was linked.
>I have reproduced something similar by linking a (dummy) shared library
>with gcc -shared (so it would get an internal copy of referenced builtin=
s)
>and then linking a program against it with g++. If the shared library w=
as
>linked with g++ -shared, all worked OK - the single copy in libstdc++ wa=
s
>used.
> =20
>
I can=C2=B4t follow you. Do you mean that the problem could be created by=
=20
mixing gcc and g++ calls?
SET
--=20
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: se...@co... se...@ie...=20
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
|
|
From: Salvador E. T. <sal...@in...> - 2004-06-14 14:48:55
|
Salvador Eduardo Tropea wrote: >> with gcc -shared (so it would get an internal copy of referenced=20 >> builtins) >> and then linking a program against it with g++. If the shared=20 >> library was >> linked with g++ -shared, all worked OK - the single copy in libstdc++ = >> was >> used. > > I have reproduced something similar by linking a (dummy) shared library= > I can=C2=B4t follow you. Do you mean that the problem could be created = by=20 > mixing gcc and g++ calls? > Just "for the records": It was the problem, using the gcc wrapper to=20 compile/link C++ code produced some change in the order of libraries=20 during the link process. Using g++ for C++ files, gcc for C files and=20 g++ to link solved the problem. Thanks, SET --=20 Salvador Eduardo Tropea (SET). (Electronics Engineer) Visit my home page: http://welcome.to/SetSoft or http://www.geocities.com/SiliconValley/Vista/6552/ Alternative e-mail: se...@co... se...@ie...=20 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013 |