|
From: Bob R. <bo...@br...> - 2004-04-08 14:09:20
|
Hello, I am just learning how to use valgrind and think it is a wonderful program. Thanks for the great work. I do have one small issue that I was hoping would be easy to solve. I am using the Memcheck skin of valgrind and I keep getting this error, ==32699== Source and destination overlap in memcpy(0x43083a74, 0x43083a74, 32) ==32699== at 0x4002068A: memcpy (../../valgrind-2.0.0/memcheck/mac_replace_strmem.c:95) ==32699== by 0x8385899: config___deep_adjust__2 (/home/BONO/bar/cvs/edg/vectors/vcast/config.ads:129) ==32699== by 0x83C0B04: config__default_config_parameters (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2366) ==32699== by 0x83C2367: config___elabb (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2415) The problem is, the source and destination are the same a lot, which I think is OK, even though it may not be good programming. Unfortunately, most of this is happening in the Ada runtime, so I can not change that. Is there any way to suppress all of these warnings? My only alternative is to just keep adding these suppressions to a file, however, there could potentially be thousands of them. Any help would be greatly appreciated. Thanks, Bob Rossi |
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 14:23:24
|
On Thu, 8 Apr 2004, Bob Rossi wrote: > I do have one small issue that I was hoping would be easy to solve. I am > using the Memcheck skin of valgrind and I keep getting this error, > > ==32699== Source and destination overlap in memcpy(0x43083a74, 0x43083a74, 32) > ==32699== at 0x4002068A: memcpy (../../valgrind-2.0.0/memcheck/mac_replace_strmem.c:95) > ==32699== by 0x8385899: config___deep_adjust__2 (/home/BONO/bar/cvs/edg/vectors/vcast/config.ads:129) > ==32699== by 0x83C0B04: config__default_config_parameters (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2366) > ==32699== by 0x83C2367: config___elabb (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2415) > > The problem is, the source and destination are the same a lot, which I > think is OK, even though it may not be good programming. Unfortunately, > most of this is happening in the Ada runtime, so I can not change that. > > Is there any way to suppress all of these warnings? Not to suppress all the warnings where the src and dst are the same. You could write a suppression to suppress all overlap errors, but I don't think you want that. > My only alternative is to just keep adding these suppressions to a file, > however, there could potentially be thousands of them. Easy option: modify memcheck/mac_replace_strmem.c:is_overlap() to not consider this an overlap -- it's a one-line change, the last case in the function, the comment explains. N |
|
From: Bob R. <bo...@br...> - 2004-04-08 14:30:20
|
On Thu, Apr 08, 2004 at 03:23:17PM +0100, Nicholas Nethercote wrote: > On Thu, 8 Apr 2004, Bob Rossi wrote: > > > I do have one small issue that I was hoping would be easy to solve. I am > > using the Memcheck skin of valgrind and I keep getting this error, > > > > ==32699== Source and destination overlap in memcpy(0x43083a74, 0x43083a74, 32) > > ==32699== at 0x4002068A: memcpy (../../valgrind-2.0.0/memcheck/mac_replace_strmem.c:95) > > ==32699== by 0x8385899: config___deep_adjust__2 (/home/BONO/bar/cvs/edg/vectors/vcast/config.ads:129) > > ==32699== by 0x83C0B04: config__default_config_parameters (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2366) > > ==32699== by 0x83C2367: config___elabb (/home/BONO/bar/cvs/edg/vectors/vcast/config.adb:2415) > > > > The problem is, the source and destination are the same a lot, which I > > think is OK, even though it may not be good programming. Unfortunately, > > most of this is happening in the Ada runtime, so I can not change that. > > > > Is there any way to suppress all of these warnings? > > Not to suppress all the warnings where the src and dst are the same. You > could write a suppression to suppress all overlap errors, but I don't > think you want that. > > > My only alternative is to just keep adding these suppressions to a file, > > however, there could potentially be thousands of them. > > Easy option: modify memcheck/mac_replace_strmem.c:is_overlap() to not > consider this an overlap -- it's a one-line change, the last case in the > function, the comment explains. Wow, that worked great. Should I make this into an option? Or will someone else take care of this? Or is this the proper work around for me? Thanks, Bob Rossi |
|
From: Nicholas N. <nj...@ca...> - 2004-04-08 14:39:22
|
On Thu, 8 Apr 2004, Bob Rossi wrote: > > Easy option: modify memcheck/mac_replace_strmem.c:is_overlap() to not > > consider this an overlap -- it's a one-line change, the last case in the > > function, the comment explains. > > Wow, that worked great. Should I make this into an option? Or will > someone else take care of this? Or is this the proper work around for > me? Probably best as a personal workaround. If 50 people had the same issue, then maybe an option would be appropriate. Until then... Valgrind has enough options already. N |
|
From: Paul L D. <pld...@pl...> - 2004-04-08 14:29:43
|
Hi Bob, > > The problem is, the source and destination are the same a lot, which I > think is OK, even though it may not be good programming. Unfortunately, Use memmove() --- if you can, not sure if you can't modify the Ada source. Other than that, you perhaps will have to go the route of using a 'temporary' holding variable. > Is there any way to suppress all of these warnings? use --gen-suppressions=yes if you really must, and add them into your default.supp file.... one should eliminate the errors for all instances of the memcpy() calls. Regards. -- Paul L Daniels - PLD Software - Xamime Unix systems Internet Development A.B.N. 19 500 721 806 ICQ#103642862,AOL:pldsoftware,Yahoo:pldaniels73 PGP Public Key at http://www.pldaniels.com/gpg-keys.pld |
|
From: Tom H. <th...@cy...> - 2004-04-08 14:32:40
|
In message <20040408140907.GA5369@white>
Bob Rossi <bo...@br...> wrote:
> The problem is, the source and destination are the same a lot, which I
> think is OK, even though it may not be good programming.
Strictly speaking it is not OK at all. Here's what the Single Unix
Specification has to say about memcpy:
"The memcpy() function shall copy n bytes from the object pointed to by
s2 into the object pointed to by s1. If copying takes place between
objects that overlap, the behavior is undefined.
The ISO C standard, to which the Single Unix Specification defers
to for memcpy as the normative reference will say something similar
although I don't haver a copy to hand.
In reality you will probably get away with it when the addresses are
the same, but there's no reason why somebody couldn't write a perverse
implementation where it would fail.
> Is there any way to suppress all of these warnings?
Well you can add Overlap suppressions, but you would have to specify
at least one routine for each one.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-04-08 14:53:05
|
> > The problem is, the source and destination are the same a lot, which I > > think is OK, even though it may not be good programming. > > Strictly speaking it is not OK at all. Here's what the Single Unix > Specification has to say about memcpy: > > "The memcpy() function shall copy n bytes from the object pointed to by > s2 into the object pointed to by s1. If copying takes place between > objects that overlap, the behavior is undefined. > > The ISO C standard, to which the Single Unix Specification defers > to for memcpy as the normative reference will say something similar > although I don't haver a copy to hand. > > In reality you will probably get away with it when the addresses are > the same, but there's no reason why somebody couldn't write a perverse > implementation where it would fail. I understand and agree completely. Unfortunately, this code is in GNAT's runtime. I don't have the option of modifying it. Apparently the code works and is really portable across UNIX machines, since GNAT ports and works in many different environments. Thanks, Bob Rossi |
|
From: Henrik N. <hn...@ma...> - 2004-04-08 17:22:49
|
On Thu, 8 Apr 2004, Bob Rossi wrote: > I understand and agree completely. Unfortunately, this code is in GNAT's > runtime. I don't have the option of modifying it. You have as much option to modify the GNAT runtime as any other Open Source program including Valgrind.. > Apparently the code works and is really portable across UNIX machines, > since GNAT ports and works in many different environments. Still this is a quite serious bug in GNAT and a bug report should be filed to have this GNAT bug fixed.. If not it will soner or later bite someone hard. Regards Henrik |