2011-01-17 6 views
1

Ich versuche Xerces-c zu lernen und folgte diesem Tutorial online.Xerces-C: Xml Parsing mehrere Dateien

http://www.yolinux.com/TUTORIALS/XML-Xerces-C.html

ich in der Lage war, das Tutorial zu bekommen durch eine Speicherprüfung (valgrind) ohne Probleme jedoch zu kompilieren und laufen, wenn ich Änderungen an das Programm leicht gemacht, kehrte die Speicherprüfung einig potenziellen Lecks Bytes. Ich habe nur ein paar zusätzliche Zeilen zu main hinzugefügt, damit das Programm zwei Dateien lesen kann.

int main() 
{ 
    string configFile="sample.xml"; // stat file. Get ambigious segfault otherwise. 

    GetConfig appConfig; 

    appConfig.readConfigFile(configFile); 

    cout << "Application option A=" << appConfig.getOptionA() << endl; 
    cout << "Application option B=" << appConfig.getOptionB() << endl; 

    // Added code 
    configFile = "sample1.xml"; 
    appConfig.readConfigFile(configFile); 

    cout << "Application option A=" << appConfig.getOptionA() << endl; 
    cout << "Application option B=" << appConfig.getOptionB() << endl; 

    return 0; 
} 

Ich frage mich, warum es ist, wenn ich die zusätzlichen Codezeilen hinzugefügt in einem anderen XML-Datei zu lesen, wäre es in der folgenden Ausgabe führen?

==776== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info 
==776== Command: ./a.out 
==776== 
Application option A=10 
Application option B=24 
Application option A=30 
Application option B=40 
==776== 
==776== HEAP SUMMARY: 
==776==  in use at exit: 6 bytes in 2 blocks 
==776== total heap usage: 4,031 allocs, 4,029 frees, 1,092,045 bytes allocated 
==776== 
==776== 3 bytes in 1 blocks are definitely lost in loss record 1 of 2 
==776== at 0x4C28B8C: operator new(unsigned long) (vg_replace_malloc.c:261) 
==776== by 0x5225E9B: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (MemoryManagerImpl.cpp:40) 
==776== by 0x53006C8: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (IconvGNUTransService.cpp:751) 
==776== by 0x4038E7: GetConfig::readConfigFile(std::string&) (in /home/bonniehan/workspace/test/a.out) 
==776== by 0x403B13: main (in /home/bonniehan/workspace/test/a.out) 
==776== 
==776== 3 bytes in 1 blocks are definitely lost in loss record 2 of 2 
==776== at 0x4C28B8C: operator new(unsigned long) (vg_replace_malloc.c:261) 
==776== by 0x5225E9B: xercesc_3_1::MemoryManagerImpl::allocate(unsigned long) (MemoryManagerImpl.cpp:40) 
==776== by 0x53006C8: xercesc_3_1::IconvGNULCPTranscoder::transcode(unsigned short const*, xercesc_3_1::MemoryManager*) (IconvGNUTransService.cpp:751) 
==776== by 0x40393F: GetConfig::readConfigFile(std::string&) (in /home/bonniehan/workspace/test/a.out) 
==776== by 0x403B13: main (in /home/bonniehan/workspace/test/a.out) 
==776== 
==776== LEAK SUMMARY: 
==776== definitely lost: 6 bytes in 2 blocks 
==776== indirectly lost: 0 bytes in 0 blocks 
==776==  possibly lost: 0 bytes in 0 blocks 
==776== still reachable: 0 bytes in 0 blocks 
==776==   suppressed: 0 bytes in 0 blocks 
==776== 
==776== For counts of detected and suppressed errors, rerun with: -v 
==776== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) 

Antwort

1

Sieht aus wie der Beispielcode einige Mängel für Ihren Anwendungsfall hat. Es enthält diesen Code:

m_OptionA = XMLString::transcode(xmlch_OptionA); 

Von the documentation wir, dass die Transcodierungs erfordert seine Anrufer sehen mit XMLString::release() den zurückgegebenen (C-Stil) Zeichenfolge freizugeben. Wir können sehen, dass dies in dem GetConfig destructor getan wird:

if(m_OptionA) XMLString::release(&m_OptionA); 

Aber dieser Code existiert nicht in readConfig(). Sie sollten es dort hinzufügen. Sie können diese C-style-Zeichenfolgenelemente auch im Konstruktor auf NULL initialisieren, oder Sie sehen sich einem anderen Speicherproblem (möglicherweise einem Absturzfehler) gegenüber, wenn Sie null anstatt mal ein oder zwei readConfig() aufrufen.

+0

Ah Ich habe versucht, die Freigabe in der Funktion readConfig() und es funktionierte perfekt. Das einzige Problem war, dass ich die print-Anweisungen aufrufen musste, bevor die Membervariablen freigegeben wurden. Vielen Dank. – user459811

+0

Großartig. Vielleicht wären Sie so freundlich, meine Antwort als akzeptiert zu markieren. –