Question

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

==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;
}

Answer 1

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

我怀疑这是因为应用于26字节对象的优化strlen操作，该对象包含25个字符的字符串。

尽管你的论点是两个系统使用的是相同的编译器，但系统之间在编译strlen调用的方式上可能存在一些差异，或者其他一些差异，见下文。

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

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

所以，总而言之，这个Valgrind错误可能并没有指出东京内阁的任何错误。

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

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

在一个系统上，优化的strlen可能正在处理一个大小可以被4整除的malloced对象，因此循环优化不会产生越界访问。

使用Valgrind进行奇怪的无效读取

1 个答案: