2011-11-16 5 views
1

Même après l'introduction d'un valgrind de fuite de mémoire intentionnelle montre:Valgrind est pas instrumenter: "utilisation du tas total: 0 allocs, 0 libère, 0 octets alloués"

==13483== HEAP SUMMARY: 
==13483==  in use at exit: 0 bytes in 0 blocks 
==13483== total heap usage: 0 allocs, 0 frees, 0 bytes allocated 
==13483== 
==13483== All heap blocks were freed -- no leaks are possible 

Le fichier exécutable a été compilé avec G ++ 4.1.2 et 4.6.2 avec:

g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -pthread -Wno-long-long -Wno-uninitialized <snipped definitions and include directives from the build system> 

J'ai essayé avec Valgrind 3.5.0 et 3.6.1 comme:

valgrind --leak-check=full --undef-value-errors=no --show-reachable=yes <executable args> 

Dans e cadre e de la bibliothèque, je travaille, je suis à l'aide d'un simple cas de test:

#include "pwiz/utility/misc/Std.hpp" 
#include "pwiz/utility/misc/Filesystem.hpp" 
#include "pwiz/data/identdata/IdentDataFile.hpp" 

using namespace pwiz::cv; 
using namespace pwiz::data; 
using namespace pwiz::identdata; 
using namespace pwiz::util; 

int main(int argc, char** argv) 
{ 
    vector<string> args(argv+1, argv+argc); 
    BOOST_FOREACH(const bfs::path& filename, args) 
    { 
     // intentional memory leak 
     IdentDataFile* idp = new IdentDataFile(filename.string()); 
     IdentDataFile& id = *idp; 
     cout << filename.string() << " " 
      << id.analysisCollection.spectrumIdentification[0]->activityDate << " " 
      << id.analysisCollection.spectrumIdentification[0]->spectrumIdentificationListPtr->spectrumIdentificationResult.size() 
      << "\n"; 
    } 
    return 0; 
} 

Évidemment, je ne pense pas que les autres soient en mesure de compiler, mais de toute façon je soupçonne que c'est quelque chose au sujet de la bibliothèque ça fait trébucher Valgrind donc un test plus simple serait inutile. Et je sais que la boucle for est en cours d'exécution car j'obtiens la sortie cout lors de l'exécution de Valgrind. Comment puis-je le déboguer sans simplifier davantage?

+0

Quelles sortes de fuites produisez-vous? – cnicutar

+0

La fuite intentionnelle est une simple déclaration «nouvelle» qui n'a pas de «suppression» correspondante. –

+0

Pouvez-vous fournir la source? Est-il possible que vous ayez personnalisé 'operator new()' là? –

Répondre

2

Il s'est résumée aux options de l'éditeur de liens en fait. Je compilais avec -static, donc valgrind n'a pas eu l'occasion de substituer sa propre implémentation de malloc. Malheureusement, Valgrind n'en avertit pas du tout!

Questions connexes