Ale*_*lds 4 c linux valgrind libc
在运行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调用以删除一个字节,那么我的gzip流会被破坏.这是原始代码:
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, i.e. 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 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,如上所述,它将行号与错误相关联.
但我只是做一些简单strncpy的argv[]变量,例如:
strncpy(uniqTag, argv[2], strlen(argv[2]) + 1);
这应该复制以null结尾的argv[2]字符串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.
在这种情况下,我会说你这样做.libc函数参数来自您的程序.我冒险猜测你的代码中有一个错误导致fwrite读取超过其源缓冲区末尾的一个字节.
编辑:
顺便说一句,这样一个小错误通常是看不见的(即你的代码不会崩溃)因为编译器和内存分配器通常都会分配特定大小的内存块并在字边缘对齐它们.这意味着很多时候,在请求的缓冲区末端有一个小区域,您可以访问它而不会触发内存保护代码.当然,如果更改编译器,libc,平台或位数(例如,从64位到32位),您的代码可能会中断.
Valgrind有针对libc中预期错误的抑制列表,您通常可以在/usr/lib64/valgrind/default.supp或/usr/lib/valgrind/default.supp中找到它.valgrind在libc中检测到了很多问题,其中许多都是为了优化代码而故意的,但是由于99%的情况下的抑制是导致问题的测试代码.
EDIT2:
请记住,与大多数调试工具一样,如果使用调试符号编译代码,Valgrind将输出有关它检测到的问题的无限更多有用信息.它将能够指出与问题相关的特定代码行 - 即使它们经常不是实际问题所在.如果您使用GCC,只需在其选项中添加-g,即可使用调试符号编译代码.但是在生产版本中,请记住删除该标志!