gpt4 book ai didi

c - 使用 Valgrind 出现奇怪的无效读取

转载 作者:行者123 更新时间:2023-11-30 15:35:19 25 4
gpt4 key购买 nike

我遇到了使用 Valgrind 进行无效读取的奇怪情况。当我运行 Tokyo Cabinet 中的示例代码时在 Valgrind valgrind-3.9.0 中使用 gcc (Debian 4.7.2-5) 4.7.2 我收到以下错误,但是,在不同的物理机器上运行它,相同的工具版本,我没有收到任何错误。知道为什么吗?

==17440== Invalid read of size 4
==17440== at 0x4E46360: tcmapputkeep2 (tokyocabinet_all.c:1705)
==17440== by 0x4E62A8A: tcpathlock (tokyocabinet_all.c:10138)
==17440== by 0x4E6E7AB: tchdbopen (tokyocabinet_all.c:11779)
==17440== by 0x4E79BCA: tcbdbopenimpl (tokyocabinet_all.c:19512)
==17440== by 0x4E7AFED: tcbdbopen (tokyocabinet_all.c:16870)
==17440== by 0x400CC9: main (in a.out)
==17440== Address 0x5f1d608 is 24 bytes inside a block of size 26 alloc'd
==17440== at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==17440== by 0x4E5A8A0: tcrealpath (tokyocabinet_all.c:7426)
==17440== by 0x4E6E797: tchdbopen (tokyocabinet_all.c:11767)
==17440== by 0x4E79BCA: tcbdbopenimpl (tokyocabinet_all.c:19512)
==17440== by 0x4E7AFED: tcbdbopen (tokyocabinet_all.c:16870)
==17440== by 0x400CC9: main (in a.out)
==17440==
hop
bar:step
baz:jump
foo:hop
==17440== Invalid read of size 4
==17440== at 0x4E46C20: tcmapout2 (tokyocabinet_all.c:1857)
==17440== by 0x4E62AF3: tcpathunlock (tokyocabinet_all.c:10150)
==17440== by 0x4E736F5: tchdbclose (tokyocabinet_all.c:11807)
==17440== by 0x4E7A857: tcbdbcloseimpl (tokyocabinet_all.c:19608)
==17440== by 0x4E7B0C7: tcbdbclose (tokyocabinet_all.c:16885)
==17440== by 0x400E9E: main (in a.out)
==17440== Address 0x5f1d608 is 24 bytes inside a block of size 26 alloc'd
==17440== at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==17440== by 0x4E5A8A0: tcrealpath (tokyocabinet_all.c:7426)
==17440== by 0x4E6E797: tchdbopen (tokyocabinet_all.c:11767)
==17440== by 0x4E79BCA: tcbdbopenimpl (tokyocabinet_all.c:19512)
==17440== by 0x4E7AFED: tcbdbopen (tokyocabinet_all.c:16870)
==17440== by 0x400CC9: main (in a.out)
<小时/>
#include <tcutil.h>
#include <tcbdb.h>
#include <stdlib.h>
#include <stdbool.h>
#include <stdint.h>

int main(int argc, char **argv){
TCBDB *bdb;
BDBCUR *cur;
int ecode;
char *key, *value;

/* create the object */
bdb = tcbdbnew();

/* open the database */
if(!tcbdbopen(bdb, "casket.tcb", BDBOWRITER | BDBOCREAT)){
ecode = tcbdbecode(bdb);
fprintf(stderr, "open error: %s\n", tcbdberrmsg(ecode));
}

/* store records */
if(!tcbdbput2(bdb, "foo", "hop") ||
!tcbdbput2(bdb, "bar", "step") ||
!tcbdbput2(bdb, "baz", "jump")){
ecode = tcbdbecode(bdb);
fprintf(stderr, "put error: %s\n", tcbdberrmsg(ecode));
}

/* retrieve records */
value = tcbdbget2(bdb, "foo");
if(value){
printf("%s\n", value);
free(value);
} else {
ecode = tcbdbecode(bdb);
fprintf(stderr, "get error: %s\n", tcbdberrmsg(ecode));
}

/* traverse records */
cur = tcbdbcurnew(bdb);
tcbdbcurfirst(cur);
while((key = tcbdbcurkey2(cur)) != NULL){
value = tcbdbcurval2(cur);
if(value){
printf("%s:%s\n", key, value);
free(value);
}
free(key);
tcbdbcurnext(cur);
}
tcbdbcurdel(cur);

/* close the database */
if(!tcbdbclose(bdb)){
ecode = tcbdbecode(bdb);
fprintf(stderr, "close error: %s\n", tcbdberrmsg(ecode));
}

/* delete the object */
tcbdbdel(bdb);

return 0;
}

最佳答案

我的直觉是 valgrind 错误是误报。

我怀疑它是由优化的 strlen 产生的操作应用于 26 字节对象,该对象包含 25 个字符的字符串。

尽管您认为这两个系统使用相同的编译器,但系统之间在 strlen 的方式上可能存在一些差异。调用已编译,或者还有其他一些差异,请参阅下面的内容。

在一个系统上,strlen 是通过对四字节字进行字对齐读取来完成的。该循环获取超出对象末尾的一些额外字节,Valgrind 将其标记为错误。

不过,这种越界访问是无害的,因为长度操作不依赖于这些字节(无论这些字节中可能有什么垃圾,它都会计算出正确的字符串长度)。此外,如果字的基地址位于映射页中,则这些越界字节不能位于未映射页中,因为该字与其大小的倍数对齐,并且基地址位于有效对象中。 (也就是说,如果 A 是可被 4 整除的地址,并且字节 A 位于有效页内,则字节 A + 1 到 A + 3 不能位于未映射页中:它们与字节 A 位于同一页中!)

所以,总而言之,这个 Valgrind 错误可能并不表明 Tokyo Cabinet 中存在任何错误。

<小时/>

两个系统之间可能存在的差异是数据库的绝对路径。

虽然你的main程序将数据库指定为相对路径 "casket.tcb" ,库使用 realpath 将其转换为绝对路径功能。字符串操作是在该路径上完成的,并且长度可能不同,除非您在两个系统上具有完全相同的目录结构并且在不同系统的相应子目录中进行这些测试。

在一个系统上,优化的strlen可能正在使用大小可被四整除的 malloc 对象,因此循环优化不会产生越界访问。

关于c - 使用 Valgrind 出现奇怪的无效读取,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22969668/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com