invalid read in mpn_copyi?
emmanuel.thome at gmail.com
Tue Jan 21 21:24:35 UTC 2014
The options --gen-suppressions and --suppressions to valgrind might be
of some use.
I'll let others answers as to whether or not the issue you encounter
is indeed a bug. I _think_ that this same thing popped up earlier, and
indeed it's an expected off-bound read caused by an sse2 load --
On Tue, Jan 21, 2014 at 9:46 PM, David Harvey <d.harvey at unsw.edu.au> wrote:
> I'm not sure if the following is considered a bug. (This was picked up by Andrew Sutherland.)
> The implementation of mpn_copyi in mpn/x86_64/core2/copyi.asm (GMP 5.1.3) generates invalid reads in certain circumstances, according to valgrind.
> Here is the code:
> #include <stdio.h>
> #include <stdlib.h>
> #include <gmp.h>
> int main(int argc, char* argv)
> long trial;
> mp_limb_t* src;
> mp_limb_t dest;
> /* try to get malloc to allocate a block of 13 * 8 bytes,
> aligned at 0x70 */
> for (trial = 0; trial < 10000; trial++)
> src = (mp_limb_t*) malloc(13 * sizeof(mp_limb_t));
> if ((((long) src) & 0xff) == 0x70)
> /* this line generates invalid read at src + 13 */
> mpn_copyi(dest, src + 5, 8);
> return 0;
> printf("could not get malloc'd block with desired alignment\n");
> return 0;
> This runs as normal with no crashes.
> However, when I run under valgrind I get:
> ==7858== Invalid read of size 8
> ==7858== at 0x4C64106: __gmpn_copyi (in /home/z2232064/temp/local/lib/libgmp.so.10.1.3)
> ==7858== by 0x3E6281ECDC: (below main) (in /lib64/libc-2.12.so)
> ==7858== Address 0x4e996d8 is 0 bytes after a block of size 104 alloc'd
> ==7858== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
> ==7858== by 0x40067F: main (in /home/z2232064/temp/thing)
> I can see why this might be considered a non-bug, and perhaps it's even intentional for performance reasons, but it seemed dodgy enough to me to report it.
> At the very least it makes it difficult to a debug a program with a tool like valgrind. We ended up rolling back to a previous version of GMP that did not exhibit this behaviour, so that we could eliminate the white noise.
> gmp-bugs mailing list
> gmp-bugs at gmplib.org
More information about the gmp-bugs