|
From: Wan M. F. W. I. <wan...@mc...> - 2011-04-12 15:51:39
|
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); COMMAND: valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./main OUTPUT: ==2421== Memcheck, a memory error detector ==2421== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2421== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==2421== Command: ./main ==2421== ==2421== ==2421== HEAP SUMMARY: ==2421== in use at exit: 0 bytes in 0 blocks ==2421== total heap usage: 1 allocs, 1 frees, 10 bytes allocated ==2421== ==2421== All heap blocks were freed -- no leaks are possible ==2421== ==2421== For counts of detected and suppressed errors, rerun with: -v ==2421== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) Regards, -- Wan Mohd Fairuz WAN ISMAIL 15 Le Palais des Fleurs, 74 Boulevard Raymond Poincare, 06160 Juan les Pins, FRANCE. http://www.watt.com.my +6 017 2071591 |
|
From: David C. <dcc...@ac...> - 2011-04-12 16:18:13
|
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 dcc...@ac...
Chapman Consulting -- San Jose, CA
|
|
From: Dave G. <go...@mc...> - 2011-04-12 17:01:26
|
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 |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-04-12 17:06:19
|
(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, 0x00002aaaaaabfde0 in memcpy () from /lib64/ld-linux-x86-64.so.2 (gdb) Continuing. Breakpoint 2, 0x00002aaaaad3f5e0 in strncpy () from /lib64/libc.so.6 (gdb) wao@dhws018: ../vg-in-place --trace-redir=yes ./m 2>&1 | 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 2>&1 | 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. |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-04-13 12:27:09
|
Looking somewhat further, I see that in fact, the replacement of memcpy is not broken. I find two memcpy: one memcpy is inside ld-linux-x86-64.so.2 (which is there very early from the start of the process and so the breakpoint was place there), and then another memcpy "appears" somewhat later in the execution (in libc.so.6). This last one is properly replaced by memcheck. So, the other reason which might explain no errors being reported is that gcc replaces a call to memcpy by an inline loop. In particular, when calling memcpy with a small hardcoded length, I see that gcc does not insert a call to memcpy but rather effectively does an inline loop. Compiling with -fno-builtin might also make the overlap error re-appearing. Note that the memcheck regression test verifying that memcpy overlaps are properly detected (overlap.vgtest) is failing on my system (due to this "inline loop" replacing the call to memcpy). Philippe ____ 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. |
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-04-14 08:44:36
|
You are right, so there is no bug for this matter. Thanks. On Wed, Apr 13, 2011 at 2:26 PM, WAROQUIERS Philippe < phi...@eu...> wrote: > Looking somewhat further, I see that in fact, the replacement of memcpy > is not broken. > I find two memcpy: one memcpy is inside ld-linux-x86-64.so.2 (which is > there very early > from the start of the process and so the breakpoint was place there), > and then another memcpy "appears" somewhat later in the execution (in > libc.so.6). > This last one is properly replaced by memcheck. > > So, the other reason which might explain no errors being reported is that > gcc replaces a call to memcpy > by an inline loop. > In particular, when calling memcpy with a small hardcoded length, I see > that gcc does not insert > a call to memcpy but rather effectively does an inline loop. > > Compiling with -fno-builtin might also make the overlap error re-appearing. > > Note that the memcheck regression test verifying that memcpy overlaps are > properly detected > (overlap.vgtest) is failing on my system (due to this "inline loop" > replacing the call to memcpy). > > Philippe > > ____ > > > > 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. > > -- Wan Mohd Fairuz WAN ISMAIL OMAP System Multimedia Integration Team Texas Instrument France f-w...@ti... +33 (0)4 93 22 20 16 +33 (0)6 43 46 13 39 15 Le Palais des Fleurs, 74 Boulevard Raymond Poincare, 06160 Juan les Pins, FRANCE. http://www.watt.com.my +6 017 2071591 |