Version: 3.5.0 (using Devel) Compiler: GCC 3.4.6 and GCC 4.1.0 CentOS 4 and CentOS 5 OS: Linux Installed from: Compiled sources mremap fails to copy rwx permissions in Valgrind 3.5.0, causes spurious invalid read and write errors. This works fine in Valgrind 3.4.1. While investigating this error I also found that the 4 argument version of mremap calls the 5 argument version with a garbage new_addr argument, which causes mremap to fail on 32-bit CentOS 5.3.
Created attachment 36291 [details] testcase which demonstrates bug output from 32-bit CentOS 5: ==2030== Memcheck, a memory error detector ==2030== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2030== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==2030== Command: ./a.out ==2030== 0x400a000 - 0x400b000 4096 mremap failed: Invalid argument ==2030== ==2030== HEAP SUMMARY: ==2030== in use at exit: 0 bytes in 0 blocks ==2030== total heap usage: 1 allocs, 1 frees, 352 bytes allocated ==2030== ==2030== All heap blocks were freed -- no leaks are possible ==2030== ==2030== For counts of detected and suppressed errors, rerun with: -v ==2030== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 8) output from 64-bit CentOS 4: ==16788== Memcheck, a memory error detector ==16788== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==16788== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==16788== Command: ./a.out ==16788== 0x4a0a000 - 0x4a0b000 4096 ==16788== Invalid write of size 1 ==16788== at 0x4907DF0: memset (mc_replace_strmem.c:586) ==16788== by 0x400704: main (mremap.c:27) ==16788== Address 0x4a0d000 is not stack'd, malloc'd or (recently) free'd ==16788== ==16788== Invalid write of size 1 ==16788== at 0x4907DF3: memset (mc_replace_strmem.c:586) ==16788== by 0x400704: main (mremap.c:27) ==16788== Address 0x4a0d001 is not stack'd, malloc'd or (recently) free'd ==16788== ==16788== Invalid write of size 1 ==16788== at 0x4907DFB: memset (mc_replace_strmem.c:586) ==16788== by 0x400704: main (mremap.c:27) ==16788== Address 0x4a0d002 is not stack'd, malloc'd or (recently) free'd ==16788== ==16788== Invalid write of size 1 ==16788== at 0x4907DFF: memset (mc_replace_strmem.c:586) ==16788== by 0x400704: main (mremap.c:27) ==16788== Address 0x4a0d003 is not stack'd, malloc'd or (recently) free'd ==16788== ==16788== Invalid write of size 1 ==16788== at 0x4907E0B: memset (mc_replace_strmem.c:586) ==16788== by 0x400704: main (mremap.c:27) ==16788== Address 0x4a0d004 is not stack'd, malloc'd or (recently) free'd ==16788== 0x4a0c000 - 0x4a0e000 8192 0x4a0e000 - 0x4a12000 16384 0x4a12000 - 0x4a1a000 32768 0x4a28000 - 0x4a38000 65536 0x4a38000 - 0x4a58000 131072 0x4a58000 - 0x4a98000 262144 0x4a98000 - 0x4b18000 524288 0x4b18000 - 0x4c18000 1048576 0x4c18000 - 0x4e18000 2097152 ==16788== ==16788== HEAP SUMMARY: ==16788== in use at exit: 0 bytes in 0 blocks ==16788== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==16788== ==16788== All heap blocks were freed -- no leaks are possible ==16788== ==16788== For counts of detected and suppressed errors, rerun with: -v ==16788== ERROR SUMMARY: 40960 errors from 5 contexts (suppressed: 4 from 4)
Created attachment 36292 [details] copy rwx permissions during mremap and zero out 5th argument to mremap when not provided
(In reply to comment #0) > [...] This works fine in Valgrind 3.4.1. Urr, that's bad. This was difficult and fiddly to get right in the first place. I'd like to get a good understanding how this got broken post 3.4.1. (That notwithstanding, your patch looks plausible to me).
It seems I independently found the permissions issue and fixed it in r11384. The business with the garbage argument when the four arg form is used still needs fixing though.
I have committed r11965 which fixes the garbage argument part of this, in a slightly different way. Specifically it makes do_remap only validate new_addr if MREMAP_FIXED was specified.