2011-01-06 9 views
6

Ich arbeite tatsächlich an einem Datenverarbeitungscode mit libxml2. Ich stecke auf einem Speicherleck fest, das unmöglich zu entfernen ist. Hier ist ein minimaler Code zu generieren:habe ich einen libxml2-Fehler gefunden (Speicherverlust beim Multithreading-Parsing)?

#include <stdlib.h> 
#include <stdio.h> 
#include <libxml/parser.h> 
#include <libxml/tree.h> 
#include <omp.h> 

int main(void) 
{ 
    xmlDoc *doc; 
    int tn; 
    char fname[32]; 

    omp_set_num_threads(2); 
    xmlInitParser(); 
    #pragma omp parallel private(doc,tn,fname) 
    { 
     tn = omp_get_thread_num(); 
     sprintf(fname,"testdoc%d.xml",tn); 
     doc = xmlReadFile(fname,NULL,0); 
     printf("document %s parsed on thread %d (%p)\n",fname,tn,doc); 
     xmlFreeDoc(doc); 
    } 
    xmlCleanupParser(); 

    return EXIT_SUCCESS; 
} 

Zur Laufzeit Ausgabe lautet:

document testdoc0.xml parsed on thread 0 (0x1005413a0) 
document testdoc1.xml parsed on thread 1 (0x1005543c0) 

bestätigt, dass wir wirklich Multi-Threading haben und dass doc ist wirklich privat in der parallelen Region. Man kann feststellen, dass ich die Thread-Sicherheitsanweisungen für die Verwendung von libxml2 (http://xmlsoft.org/threads.html) richtig angewendet habe. Valgrind Berichte:

HEAP SUMMARY: 
    in use at exit: 9,000 bytes in 8 blocks 
    total heap usage: 956 allocs, 948 frees, 184,464 bytes allocated 

968 bytes in 1 blocks are definitely lost in loss record 6 of 8 
    at 0x1000107AF: malloc (vg_replace_malloc.c:236) 
    by 0x1000B2590: xmlGetGlobalState (in /opt/local/lib/libxml2.2.dylib) 
    by 0x1000B1A18: __xmlDefaultSAXHandler (in /opt/local/lib/libxml2.2.dylib) 
    by 0x100106D18: xmlDefaultSAXHandlerInit (in /opt/local/lib/libxml2.2.dylib) 
    by 0x100041BE7: xmlInitParserCtxt (in /opt/local/lib/libxml2.2.dylib) 
    by 0x100042145: xmlNewParserCtxt (in /opt/local/lib/libxml2.2.dylib) 
    by 0x10004615E: xmlCreateURLParserCtxt (in /opt/local/lib/libxml2.2.dylib) 
    by 0x10005B56B: xmlReadFile (in /opt/local/lib/libxml2.2.dylib) 
    by 0x100000E03: main.omp_fn.0 (in ./xtest) 
    by 0x100028FA3: gomp_thread_start (in /opt/local/lib/gcc44/libgomp.1.dylib) 
    by 0x1001E8535: _pthread_start (in /usr/lib/libSystem.B.dylib) 
    by 0x1001E83E8: thread_start (in /usr/lib/libSystem.B.dylib) 

LEAK SUMMARY: 
    definitely lost: 968 bytes in 1 blocks 
    indirectly lost: 0 bytes in 0 blocks 
    possibly lost: 0 bytes in 0 blocks 
    still reachable: 8,032 bytes in 7 blocks 
     suppressed: 0 bytes in 0 blocks 
Reachable blocks (those to which a pointer was found) are not shown. 
To see them, rerun with: --leak-check=full --show-reachable=yes 

Dies funktioniert für mich, was auch immer das XML-Dokument verwendet. Ich benutze libxml 2.7.8, unter Mac OS X 10.6.5 mit gcc 4.4.5.

Kann jemand diesen Fehler reproduzieren?

Danke,

Antonin

+0

Ich sehe nicht, was dieser Code diesen Ausgang erzeugen könnte. Vielleicht hast du den Code zu sehr getrimmt. –

+0

Ist die Größe des Lecks abhängig von der zu analysierenden XML-Datei? – AShelly

+0

@Hans Passant: Ich sehe weder, warum dieser Code das tut, aber es ist, in einer sauberen Umgebung. Ich möchte wissen, ob andere Leute das reproduzieren können, bevor sie einen Fehler melden. –

Antwort

2

Sie sollten wahrscheinlich diese bringen auf der libxml2-Mailingliste.

http://mail.gnome.org/mailman/listinfo/xml

+0

Ich habe es auf die Libxml2 Bugzilla, wollte ich hier nur etwas zu posten, um zu wissen, ob jemand in der Lage ist, den Fehler zu reproduzieren. –

3

Von der Website, die Sie oben (http://xmlsoft.org/threads.html) aufgeführt:

mit 2.4.7 Starten, libxml2 Marken Bestimmungen, um sicherzustellen, dass gleichzeitige Threads können sicher parallel arbeiten verschiedene Dokumente arbeiten.

Ihr Beispiel scheint eine xmlReadFile für dasselbe Dokument (testdoc.xml) für jeden Thread zu verwenden. Weiter heißt es:

Beachten Sie, dass der Thread-Sicherheit kann nicht für mehrere Threads sichergestellt werden, das gleiche Dokument zu teilen, muss die Verriegelung auf der Anwendungsebene durchgeführt werden ...

+0

Danke, Sie haben Recht. Aber leider verwendet der ursprüngliche Code, an dem ich arbeite, wirklich verschiedene Dokumente, ich habe meinen Beispielcode geändert (und meine Frage bearbeitet) und das Leck bleibt bestehen. –

Verwandte Themen