I'm getting valgrind errors when attempting to pclose() a pipe previously open with popen(). The errors occur on Mac OS X, but not on Linux. Consider the following example:
#include <stdlib.h>
#include <stdio.h>
int main() {
FILE *fp;
char buf[4096];
if (!(fp = popen("ls", "r")))
exit(-1);
while (fscanf(fp, "%s", buf) == 1)
printf("%s\n", buf);
pclose(fp);
return 0;
}
I get the following valgrind errors on a Mac (OS X 10.6.7, valgrind version 3.6.0), except if I remove the pclose() call:
==21455== Conditional jump or move depends on uninitialised value(s)
==21455== at 0xB1992: pclose (in /usr/lib/libSystem.B.dylib)
==21455== by 0x1F16: main (in ./a.out)
==21455==
==21455== Syscall param wait4(pid) contains uninitialised byte(s)
==21455== at 0x504FA: wait4 (in /usr/lib/libSystem.B.dylib)
==21455== by 0x1F16: main (in ./a.out)
However, I don't get any errors on a Linux system with valgrind version 3.5.0.
Any ideas on what could be causing the errors on the Mac?
Update
Turning on --track-origins in valgrind shows that the origin of the problem might be in the popen() call. Got the same thing with gcc 4.2.1 and 4.5.3.
==4425== Conditional jump or move depends on uninitialised value(s)
==4425== at 0xB1992: pclose (in /usr/lib/libSystem.B.dylib)
==4425== by 0x1F18: main (in ./a.out)
==4425== Uninitialised value was created by a stack allocation
==4425== at 0xB14C5: popen$UNIX2003 (in /usr/lib/libSystem.B.dylib)
==4425==
==4425== Syscall param wait4(pid) contains uninitialised byte(s)
==4425== at 0x504FA: wait4 (in /usr/lib/libSystem.B.dylib)
==4425== by 0x1F18: main (in ./a.out)
==4425== Uninitialised value was created by a stack allocation
==4425== at 0xB14C5: popen$UNIX2003 (in /usr/lib/libSystem.B.dylib)
It is quite common for system libraries to pass uninitialized bytes to system calls. It is less common for conditional jump to depend on uninitialized value, but it does happen (glibc-2.X.supp in my Linux build contains 8 suppressions for this in glibc).
Since there is nothing you can do about these errors anyway, you should just suppress them. See --gen-suppressions in Valgrind docs.
The reported problem seems to be internal to the system library, not in your code.
I too get no errors using MacOS X 10.6.8, Valgrind 3.6.0, and either (Apple's) GCC 4.2.1 or (my) GCC 4.6.0. I do get compilation warnings from your code (4.6.0 shown) - actually, I have 'make' run the command and the makefile contains all those -Wxxx arguments:
$ gcc -g -std=c99 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition vg.c -o vg
vg.c:4:5: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
vg.c: In function ‘main’:
vg.c:4:5: warning: old-style function definition [-Wold-style-definition]
$ valgrind vg
==40593== Memcheck, a memory error detector
==40593== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==40593== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==40593== Command: vg
==40593==
vg
vg.c
vg.dSYM
==40593==
==40593== HEAP SUMMARY:
==40593== in use at exit: 4,184 bytes in 2 blocks
==40593== total heap usage: 6 allocs, 4 frees, 26,848 bytes allocated
==40593==
==40593== LEAK SUMMARY:
==40593== definitely lost: 0 bytes in 0 blocks
==40593== indirectly lost: 0 bytes in 0 blocks
==40593== possibly lost: 0 bytes in 0 blocks
==40593== still reachable: 4,184 bytes in 2 blocks
==40593== suppressed: 0 bytes in 0 blocks
==40593== Rerun with --leak-check=full to see details of leaked memory
==40593==
==40593== For counts of detected and suppressed errors, rerun with: -v
==40593== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$ cc --version
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.9)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc --version
gcc (GCC) 4.6.0
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ valgrind --version
valgrind-3.6.0
Localhost JL: uname -a
Darwin localhost 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
$ otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 315.0.0)
When run with -v --gen-suppressions=yes, valgrind reports a lot more information, but there are still no suppressed errors.
This error appears resolved in latest Valgrind SVN source. A number of internal bugs in Valgrind have been resolved, as well as known Apple system library bugs suppressed.
Note this is running on OS X 10.10.4
$ ./vg-in-place ../../test
==55558== Memcheck, a memory error detector
==55558== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==55558== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==55558== Command: ../../test
==55558==
--55558-- ../../test:
--55558-- dSYM directory is missing; consider using --dsymutil=yes
AUTHORS
COPYING
COPYING.DOCS
Makefile
...
vg-in-place
xfree-3.supp
xfree-4.supp
==55558==
==55558== HEAP SUMMARY:
==55558== in use at exit: 39,331 bytes in 419 blocks
==55558== total heap usage: 523 allocs, 104 frees, 68,971 bytes allocated
==55558==
==55558== LEAK SUMMARY:
==55558== definitely lost: 0 bytes in 0 blocks
==55558== indirectly lost: 0 bytes in 0 blocks
==55558== possibly lost: 0 bytes in 0 blocks
==55558== still reachable: 0 bytes in 0 blocks
==55558== suppressed: 39,331 bytes in 419 blocks
==55558==
==55558== For counts of detected and suppressed errors, rerun with: -v
==55558== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$ ./vg-in-place --version
valgrind-3.11.0.SVN
来源：https://stackoverflow.com/questions/6541100/valgrind-errors-caused-by-pclose-on-mac-os-x