2010-10-06 2 views
9

Hier ist der Valgring Bericht:Wie findet man einen freien/löschenden Unterschied, der von Valgrind in einem Multithread-Programm gemeldet wird?

==14546== Thread 5: 
==14546== Invalid free()/delete/delete[] 
==14546== at 0x490555D: free (vg_replace_malloc.c:235) 
==14546== by 0x3BF7EFAA8F: free_mem (in /lib64/tls/libc-2.3.4.so) 
==14546== by 0x3BF7EFA581: __libc_freeres (in /lib64/tls/libc-2.3.4.so) 
==14546== by 0x4802676: _vgw_freeres (vg_preloaded.c:62) 
==14546== Address 0x4DC4EE0 is not stack'd, malloc'd or (recently) free'd 

Wie kann ich wissen, welcher Thread ist es, als die Thread-Nummer von einer Ausführung zur anderen variiert? Wird assigning names to my threads hier helfen?

BEARBEITEN: Ich glaube nicht, dass es so ist, wie dies im DRD-Abschnitt des Handbuchs erwähnt wird.

Ich benutze Valgrind-3.1.1 auf Red Hat Enterprise Linux AS4.

Antwort

2

Ich fand schließlich die Erklärung dafür: meine Unit-Test ausführbare Datei wurde auf eine [Dritte] Bibliothek verknüpft es didn benutze es nicht. Ich habe es ohne diese Bibliothek neu verknüpft und das Problem ging weg.

Auch der Fehler wurde in __libc_freeres(), eine Funktion der gnu libc, die freie Ressourcen am Ende der Ausführung erkannt. Das Problem könnte in der Bibliothek oder im glibc liegen.
Die folgenden Valgrind Linux-specific option können verwendet werden, um diesen Fehler zu vermeiden: --run-libc-freeres=no. Beachten Sie, dass dies die Lecksuche weniger effizient machen kann.

1

Sie können das Makro DRD_GET_DRD_THREADID verwenden, um die Thread-IDs anzuzeigen, wenn der Thread gestartet wird. Sie können auch einen Namen im Ausdruck angeben, um zu helfen. Siehe die DRD Manual

EDIT Vielleicht bin ich hier nicht spezifisch .. aber ich denke, Sie werden in einigen valgrind Libs verknüpfen müssen, wenn Sie eine Debug-Version des Codes bauen (vielleicht mit einer Kompilierung Option oder etwas) . Sie können die DRD_GET_DRD_THREADID innerhalb des Threads verwenden und einen Namen erhalten, den Sie beim Start zugewiesen haben. Anschließend können Sie diese Informationen in eine Datei oder auf die Konsole schreiben. Es gibt keine Möglichkeit, DRD zu sagen, dass ich den Namen drucken soll, den ich nicht denke, also muss man eine Combo verwenden.

6

Sie geben wahrscheinlich eine globale Variable frei (die Adresse: 0x4DC4EE0 ist sehr nah an der Stelle, wo Globals standardmäßig unter Linux/x86_64 leben).

Führen Sie das Programm unter GDB, dann tun Sie info symbol 0x4DC4EE0, und GDB sollte Ihnen alles sagen, was Sie wissen müssen.

Update:
Valgrind 3.6 meldet das globale Symbol bereits. Zum Beispiel dieses Buggy Programm gegeben:

#include <stdlib.h> 

int x; 

int main() 
{ 
    free(&x); 
    return 0; 
} 

Valgrind 3.6 Berichte:

==18731== Invalid free()/delete/delete[] 
==18731== at 0x4C240E8: free /tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:394 
==18731== by 0x4004AA: main /home/t.c:7 
==18731== Address 0x60089c is 0 bytes inside data symbol "x" 
+0

Danke, ich habe bereits ein Bild von meinem Prozess erstellt und gdb ''info address' und jetzt auch' info symbol' aufgerufen, bisher aber kein Glück. – philant