Das von Ihnen bereitgestellte Trivialprogramm (mit dem Namen ValgrindTest) ist ein einfaches Hallo-Welt-Programm, das in C geschrieben ist.
#include <iostream> int main() { return 0; }
Wenn dieses Programm mit Valgrind (Version 3.10.1) ausgeführt wird, meldet es, dass 72.704 Bytes darin sind 1 Block, der noch erreichbar ist:
$ valgrind --leak-check=full --track-origins=yes --show-reachable=yes ./ValgrindTest ==27671== Memcheck, a memory error detector ==27671== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==27671== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==27671== Command: ./ValgrindTest ==27671== ==27671== ==27671== HEAP SUMMARY: ==27671== in use at exit: 72,704 bytes in 1 blocks ==27671== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated ==27671== ==27671== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 ==27671== at 0x4C2AB9D: malloc (vg_replace_malloc.c:296) ==27671== by 0x4EC060F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21) ==27671== by 0x400F305: call_init.part.0 (dl-init.c:85) ==27671== by 0x400F3DE: call_init (dl-init.c:52) ==27671== by 0x400F3DE: _dl_init (dl-init.c:134) ==27671== by 0x40016E9: ??? (in /lib/x86_64-linux-gnu/ld-2.15.so) ==27671== ==27671== LEAK SUMMARY: ==27671== definitely lost: 0 bytes in 0 blocks ==27671== indirectly lost: 0 bytes in 0 blocks ==27671== possibly lost: 0 bytes in 0 blocks ==27671== still reachable: 72,704 bytes in 1 blocks ==27671== suppressed: 0 bytes in 0 blocks ==27671== ==27671== For counts of detected and suppressed errors, rerun with: -v ==27671== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Sie machen sich keine Gedanken darüber, ob Sie sich wegen der Still-Reachable-Warnung Sorgen machen sollen oder nicht, aber Sie haben danach gefragt Wie das einfache Einfügen eines Standardbibliotheksheaders zu einer Warnung führen könnte, dass er noch erreichbar ist, wenn im Programm selbst keine Objekte aus dieser Bibliothek zugewiesen wurden.
Die Antwort ist, dass die C-Standardbibliothek ihren verwendet eigenes Speicherverwaltungssystem, das Speicher vom Betriebssystem zuweist und diesen Speicher dann selbst verwaltet. Wenn Sie einen Standardbibliotheksheader einfügen, verknüpfen Sie Ihr Programm im Wesentlichen mit dem Standardbibliothekscode, der dieses Speicherverwaltungssystem enthält. Dadurch ist der durch den Standardbibliothekscode zugewiesene Speicher weiterhin von Ihrem Programm aus erreichbar, auch wenn Sie selbst keine Objekte explizit aus der Standardbibliothek zuweisen.
Es gibt zwei Möglichkeiten, die Warnung „Noch erreichbar“ zu beheben:
Ignorieren Sie die Warnung „immer noch erreichbar“. Wenn ja Wenn Sie sich keine Sorgen über Speicherlecks machen, können Sie die Warnung „Noch erreichbar“ einfach ignorieren. Dazu können Sie beim Ausführen von Valgrind das Flag --leak-check=no setzen:
valgrind --leak-check=no ./ValgrindTest
Es ist wichtig, sich daran zu erinnern, dass immer noch erreichbar ist Warnungen weisen nicht unbedingt auf einen Speicherverlust hin. In diesem Fall wird die Warnung „Noch erreichbar“ durch das Speicherverwaltungssystem der Standardbibliothek verursacht und kann getrost ignoriert werden, wenn Sie sich keine Sorgen über Speicherlecks machen.
Das obige ist der detaillierte Inhalt vonWarum zeigt ein einfaches C-Hello-World-Programm, wenn es mit Valgrind ausgeführt wird, eine Warnung zum „immer noch erreichbaren' Speicher an, obwohl kein Speicher zugewiesen wird?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!