Re: [Valgrind-users] Memcheck not behave as expected : Overlapping src and dst pointers in memcpy

[David Chapman]

On 4/12/2011 8:24 AM, Wan Mohd Fairuz Wan Ismail wrote:

Hi,
I did a simple code to test out Overlapping |src| and |dst| pointers 
in |memcpy |using memcheck. But it seems memcheck don't detect the src 
and dst addresses are identical. Any idea?


CODE:
char* arr  = malloc(10);
memcpy(arr, arr, 10);
free(arr);





This is correct; memcpy() does not perform this check.  Look at the man 
page for it and memmove().


--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Memcheck not behave as expected : Overlapping src and dst pointers in memcpy

[Dave Goodell]

On Apr 12, 2011, at 11:18 AM CDT, David Chapman wrote:

 On 4/12/2011 8:24 AM, Wan Mohd Fairuz Wan Ismail wrote:
 Hi,
 I did a simple code to test out Overlapping src and dst pointers in memcpy 
 using memcheck. But it seems memcheck don't detect the src and dst addresses 
 are identical. Any idea?
 
 CODE:
 char* arr  = malloc(10);
 memcpy(arr, arr, 10); 
 free(arr);
 
 This is correct; memcpy() does not perform this check.  Look at the man page 
 for it and memmove().

I think the OP's point was that while memcpy may not make this check, the 
Valgrind tool memcheck should catch this usage and report a warning for it, a 
point that I agree with.  It's not especially different in my mind from passing 
undefined values into a system call (which memcheck does catch), since the 
behavior in both cases is undefined and likely to cause a problem in your code 
on at least some platforms.

-Dave



--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Memcheck not behave as expected : Overlapping src and dst pointers in memcpy

[WAROQUIERS Philippe]

(David: memcpy does not do an overlap check, but Valgrind is there to do
these missing checks :).

I confirm that the memcpy overlap error is not reported anymore by
Valgrind :
I have tried at work with a 3.7.0 SVN, and it looks like the memcpy
overlap check is broken.

Investigating a little bit, it looks like the memcpy has moved of
library (probably relatively recently,
probably with a red-hat update) on my system here (red-hat 5.2, 64 bit
library).

A small test works (i.e. reports an overlap) when compiled in 32 bits,
but does not report the overlap
error when compiled in 64 bits.


The problem looks in the interception and replacement of memcpy (not
done anymore in 64 bits)
while e.g. the replacement of strncpy still works ok (see below for
details).

The best is to file a bug giving e.g. the below information (and/or a
similar information for your system,
if it does not match the below).

Philippe



Breakpoint 1, 0x2aabfde0 in memcpy () from
/lib64/ld-linux-x86-64.so.2
(gdb)
Continuing.

Breakpoint 2, 0x2ad3f5e0 in strncpy () from /lib64/libc.so.6
(gdb)


wao@dhws018: ../vg-in-place --trace-redir=yes ./m 21 | grep memcpy
--17887--  libc.so*  memcpy
R- 0x04c23210
--17887--  ld.so.1   memcpy
R- 0x04c22ff0
--17887--  ld64.so.1 memcpy
R- 0x04c22dd0
--17887--  NONE  _intel_fast_memcpy
R- 0x04c22bb0
--17887--  libc.so*  __memcpy_chk
R- 0x04c22570
--17887--  libc.so*  memcpy
R- 0x04c23210
--17887--  ld.so.1   memcpy
R- 0x04c22ff0
--17887--  ld64.so.1 memcpy
R- 0x04c22dd0
--17887--  NONE  _intel_fast_memcpy
R- 0x04c22bb0
--17887--  libc.so*  __memcpy_chk
R- 0x04c22570
--17887-- 0x04ea0040 (__memcpy_chk) R- 0x04c22570
__memcpy_chk
--17887-- 0x04ea0050 (memcpy  ) R- 0x04c23210 memcpy
wao@dhws018:

wao@dhws018: ../vg-in-place --trace-redir=yes ./m 21 | grep strncpy
--20181--  libc.so*  strncpy
R- 0x04c23550
--20181--  libc.so*  __GI_strncpy
R- 0x04c23430
--20181--  libc.so*  strncpy
R- 0x04c23550
--20181--  libc.so*  __GI_strncpy
R- 0x04c23430
--20181-- 0x04e9e5e0 (strncpy ) R- 0x04c23550 strncpy
--20181-- REDIR: 0x4e9e5e0 (strncpy) redirected to 0x4c23550 (strncpy)
==20181==at 0x4C23567: strncpy (mc_replace_strmem.c:339)
==20181== Source and destination overlap in strncpy(0x5179040,
0x5179042, 5)
==20181==at 0x4C23617: strncpy (mc_replace_strmem.c:339)
wao@dhws018:




 
This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.
 
Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL, unless it is confirmed by appropriately signed hard 
copy.
 
Any views expressed in this message are those of the sender.--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users