Valgrind breaks with dirname? - c++

Question

==11136== Invalid read of size 8
==11136== at 0x5AFC696: memrchr (memrchr.S:289)
==11136== by 0x5B57FAF: dirname (dirname.c:45)
==11136== by 0x405F43: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:379)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136== Address 0x640daf8 is 8 bytes inside a block of size 10 alloc'd
==11136== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11136== by 0x5AEF801: strdup (strdup.c:43)
==11136== by 0x405EF2: push::lg_cmd_dirname(push::Env&) (LGExtension.cpp:369)
==11136== by 0x42533C: push::Instruction::operator()(push::Env&) const (in /home/bots/svn/eco/branches/skynet_BigPUSH/src/push3.0/extension/push_bloodline)
==11136== by 0x488ECD: push::Env::go(int) (Env.cpp:72)
==11136== by 0x4A84D5: main (bloodline.cpp:99)
==11136==
Is this a legitimate error? It looks like the read takes place inside a valid block. In my program, the call looks like this:
char *path = strdup(full_path.c_str());
cerr << "Path is : " << path << endl;
result = dirname(path);
if(result < 0){
cerr << "Dirname failed for some reason. Check log." << endl;
}
and the output to cerr at the time of the error is:
Path is : /tmp/tmp/
which is a valid path. Dirname shouldn't have any trouble with this, and it's operating on a heap allocated duplicate.
EDIT:
Here is a minimal example that will produce this error:
#include <string.h>
#include <stdio.h>
#include <iostream>
#include <libgen.h>
int main(){
char *path = strdup("/tmp/tmp/");
char* result = dirname(path);
std::cerr << result << std::endl;
}
compile with g++.
run with valgrind, and you get:
==32466== Memcheck, a memory error detector
==32466== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==32466== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==32466== Command: ./a.out
==32466==
==32466== Invalid read of size 8
==32466== at 0x51C7696: memrchr (memrchr.S:289)
==32466== by 0x5222FAF: dirname (dirname.c:45)
==32466== by 0x400865: main (in /home/j3doucet/a.out)
==32466== Address 0x59ff048 is 8 bytes inside a block of size 10 alloc'd
==32466== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32466== by 0x51BA801: strdup (strdup.c:43)
==32466== by 0x400855: main (in /home/j3doucet/a.out)
==32466==
/tmp
==32466==
==32466== HEAP SUMMARY:
==32466== in use at exit: 10 bytes in 1 blocks
==32466== total heap usage: 1 allocs, 0 frees, 10 bytes allocated
==32466==
==32466== LEAK SUMMARY:
==32466== definitely lost: 10 bytes in 1 blocks
==32466== indirectly lost: 0 bytes in 0 blocks
==32466== possibly lost: 0 bytes in 0 blocks
==32466== still reachable: 0 bytes in 0 blocks
==32466== suppressed: 0 bytes in 0 blocks
==32466== Rerun with --leak-check=full to see details of leaked memory
==32466==
==32466== For counts of detected and suppressed errors, rerun with: -v
==32466== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

Answer 1

Valgrind indicates that a read of size 8 is done from the byte nr 8 in
a block of 10 bytes.
This read is done by memrchr.
Such functions are often optimised based on the assumption that you can read
more bytes than the allocated block.
To avoid reporting such problems, Valgrind has to replace such optimised
functions by its own redefining function.
memrchr has only been redefined in Valgrind from version 3.8 onwards.
=> you should retry with the latest version of Valgrind (3.8.1).
Error might then not be reported anymore (assuming it is effectively a false positive
due to non redefinition of memrchr).