我需要担心Valgrind在申请范围之外报告错误吗？

运行Valgrind的memcheck工具时，我经常会得到几十万（或更多，因为Valgrind在100K切断）小的无效读取语句，例如：

 ==32027== Invalid read of size 1 ==32027== at 0x3AB426E26A: _IO_default_xsputn (in /lib64/libc-2.5.so) ==32027== by 0x3AB426CF70: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.5.so) ==32027== by 0x3AB42621FA: fwrite (in /lib64/libc-2.5.so) ==32027== by 0x4018CA: STARCH_gzip_deflate (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32027== by 0x401F48: compressFileWithGzip (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32027== by 0x4028B5: transformInput (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32027== by 0x402F12: main (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32027== Address 0x7febb9b3c is on thread 1's stack 

这些语句是指调用我的应用程序之外的函数（“ starch ”），它似乎是libc一部分。 这是我需要关心的吗？

编辑

如果我修改fwrite调用删除一个字节，那么我的gzipstream被损坏。 这是原来的代码：

• 使用linux perf工具测量应用程序的FLOP
• 如何在Linux下用C实现定时器的callback函数
• Linux中的分叉在堆内
• linux – 获取进程的PID
• 如果variables属于堆或堆栈，我可以通过GDB查找吗？

 int STARCH_gzip_deflate(FILE *source, FILE *dest, int level) { int ret, flush; unsigned have; z_stream strm; unsigned char in[STARCH_Z_CHUNK]; unsigned char out[STARCH_Z_CHUNK]; /* initialize deflate state */ strm.zalloc = Z_NULL; strm.zfree = Z_NULL; strm.opaque = Z_NULL; /* deflateInit2 allows creation of archive with gzip header, ie a gzip file */ /* cf. http://www.zlib.net/manual.html */ ret = deflateInit2(&strm, level, Z_DEFLATED, (15+16), 8, Z_DEFAULT_STRATEGY); if (ret != Z_OK) return ret; /* compress until end of file */ do { strm.avail_in = fread(in, 1, STARCH_Z_CHUNK, source); if (ferror(source)) { (void)deflateEnd(&strm); return Z_ERRNO; } flush = feof(source) ? Z_FINISH : Z_NO_FLUSH; strm.next_in = in; do { strm.avail_out = STARCH_Z_CHUNK; strm.next_out = out; ret = deflate(&strm, flush); assert(ret != Z_STREAM_ERROR); have = STARCH_Z_CHUNK - strm.avail_out; /* invalid read happens here */ if (fwrite(out, 1, have, dest) != have || ferror(dest)) { (void)deflateEnd(&strm); return Z_ERRNO; } } while (strm.avail_out == 0); assert(strm.avail_in == 0); } while (flush != Z_FINISH); assert(ret == Z_STREAM_END); /* clean up and return */ (void)deflateEnd(&strm); return Z_OK; } 

编辑2

我想我看到了这个问题。 我in[STARCH_Z_CHUNK]而不是in[STARCH_Z_CHUNK + 1] （同样out[] ）。 如果我调整fread和fwrite语句的-1 ，我似乎并没有得到那些Invalid read of size 1语句的Invalid read of size 1 ，尽pipe我仍然看到很多Invalid read of size 4和8特定于zlib ：

 ==32624== Invalid read of size 4 ==32624== at 0x3AB5206455: deflateInit2_ (in /usr/lib64/libz.so.1.2.3) ==32624== by 0x40180E: STARCH_gzip_deflate (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32624== by 0x401F48: compressFileWithGzip (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32624== by 0x402C03: transformInput (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32624== by 0x402F12: main (in /home/areynolds/trunk/utility/applications/bed/starch/bin/starch) ==32624== Address 0x7feafde38 is on thread 1's stack 

编辑3

我正在用-g重新编译，如前所述，它将行号与错误联系起来。

但是我只是做一个简单的argv[]variables，例如：

 strncpy(uniqTag, argv[2], strlen(argv[2]) + 1); 

这应该复制以null结尾的argv[2]string到uniqTag ，但是valgrind仍然将其标记为错误。

编辑4

这里是错误信息：

 ==3682== Invalid read of size 1 ==3682== at 0x4A081C1: strncpy (mc_replace_strmem.c:329) ==3682== by 0x4022F1: parseCommandLineInputs (starch.c:589) ==3682== by 0x402F20: main (starch.c:46) ==3682== Address 0x7fedffe11 is on thread 1's stac 

这是两条相关的路线。 valgrind在说第二行是无效的读取：

 uniqTag = (char *)malloc(strlen(argv[2]) + 1); strncpy(uniqTag, argv[2], strlen(argv[2]) + 1); 

因为strlen(argv[2]) + 1 > strlen(argv[2]) ，这应该导致以null结尾的uniqTag 。