Verwenden von Valgrind, um ein Speicherleck im mysql C++ - Client zu finden

Question

Ich benutze Valgrind, um zu versuchen, einen Speicherverlust zu finden, ist der mysql C++ - Client von mysql verteilt.

In den Beispielen (resultset.cpp) und meinem eigenen Programm gibt es einen einzelnen 56-Byte-Block, der nicht freigegeben ist. In meinem eigenen Programm habe ich das Leck zu einem Aufruf des mysql-Clients verfolgt.

Hier sind die Ergebnisse, wenn ich den Test ausführen:

valgrind --leak-check=full --show-reachable=yes ./my-executable 

==29858== Memcheck, a memory error detector 
==29858== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. 
==29858== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info 
==29858== Command: ./my-executable 
==29858== 
==29858== 
==29858== HEAP SUMMARY: 
==29858==  in use at exit: 56 bytes in 1 blocks 
==29858== total heap usage: 693 allocs, 692 frees, 308,667 bytes allocated 
==29858== 
==29858== 56 bytes in 1 blocks are still reachable in loss record 1 of 1 
==29858== at 0x4C284A8: malloc (vg_replace_malloc.c:236) 
==29858== by 0x400D334: _dl_map_object_deps (dl-deps.c:506) 
==29858== by 0x4013652: dl_open_worker (dl-open.c:291) 
==29858== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==29858== by 0x4012FF9: _dl_open (dl-open.c:583) 
==29858== by 0x7077BCF: do_dlopen (dl-libc.c:86) 
==29858== by 0x400E9C5: _dl_catch_error (dl-error.c:178) 
==29858== by 0x7077D26: __libc_dlopen_mode (dl-libc.c:47) 
==29858== by 0x72E5FEB: pthread_cancel_init (unwind-forcedunwind.c:53) 
==29858== by 0x72E614B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126) 
==29858== by 0x72E408F: __pthread_unwind (unwind.c:130) 
==29858== by 0x72DDEB4: pthread_exit (pthreadP.h:265) 
==29858== 
==29858== LEAK SUMMARY: 
==29858== definitely lost: 0 bytes in 0 blocks 
==29858== indirectly lost: 0 bytes in 0 blocks 
==29858==  possibly lost: 0 bytes in 0 blocks 
==29858== still reachable: 56 bytes in 1 blocks 
==29858==   suppressed: 0 bytes in 0 blocks 
==29858== 
==29858== For counts of detected and suppressed errors, rerun with: -v 
==29858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6) 

Ich habe ein paar Fragen in Bezug auf diese:

1. Wie soll ich das --show-Block erreichbar interpretieren?
2. Ist dieser Block nützlich für mich, um den Fehler auf Null zu setzen?
3. Wenn der Block nicht nützlich ist, hat Valgrind einen anderen Mechanismus, der mir hilft, das Leck zu verfolgen?
4. Wenn nicht, gibt es ein anderes Tool (hoffentlich OSS auf Linux), um mir dabei zu helfen, dies einzugrenzen?

Vielen Dank im Voraus ..

UPDATE: Hier ist der Code, den ich auf meinem System für die Definition von pthread_exit gefunden. Ich bin nicht sicher, dass dies die eigentliche Quelle ist, die aufgerufen wird. Aber wenn dem so ist, kann jemand erklären, was schief gehen könnte?

void 
pthread_exit (void *retval) 
{ 
    /* specific to PTHREAD_TO_WINTHREAD */ 

    ExitThread ((DWORD) ((size_t) retval)); /* thread becomes signalled so its death can be waited upon */ 
    /*NOTREACHED*/ 
    assert (0); return; /* void fnc; can't return an error code */ 
} 

Answer 1

Erreichbar bedeutet nur, dass die Blöcke einen gültigen Zeiger hatten sie in ihrem Umfang verweisen, wenn das Programm verlassen, was darauf hindeutet, dass das Programm nicht ausdrücklich frei, alles auf Ausgang, weil es auf dem zugrunde liegende Betriebssystem angewiesen, dies zu tun. Was Sie suchen sollten, sind verlorene Blöcke, in denen Speicherblöcke alle Verweise auf sie verloren haben und nicht mehr freigegeben werden können.

Also, die 56 Bytes wurden wahrscheinlich in Haupt zugeordnet, die sie nicht explizit frei. Was Sie gepostet haben, zeigt kein Speicherleck. Es zeigt, dass main alles freigibt, was main zugewiesen ist, da main annimmt, dass der gesamte Speicher vom Kernel zurückgewonnen wird, wenn er stirbt.

Spezifisch ist es pthread (im Hauptteil), der diese Annahme bildet (die eine gültige Annahme auf darn nahe allem ist, das in der Produktion gefunden wird, die in den letzten 15+ Jahren geschrieben wird). Die Notwendigkeit, Blöcke, die beim Beenden noch einen gültigen Verweis enthalten, freizugeben, ist ein bisschen umstritten, aber für diese spezifische Frage muss nur erwähnt werden, dass die Annahme gemacht wurde.

bearbeiten

Es ist eigentlich pthread_exit() nicht etwas nach oben an der Ausfahrt Reinigung, aber ist es wahrscheinlich nicht brauchen, um (oder möglicherweise kann nicht), sobald sie diesen Punkt erreicht, wie erläutert.