NCurses Speicherzuweisung valgrind Nachricht

Question

Ich habe mich NCurses in letzter Zeit gelehrt und ich beschloss, meinen Code in Valgrind zu überprüfen, um Speicherlecks zu überprüfen. Diese kleine Menge an Code gibt das gleiche Fehlerergebnis wie mein Programm und ich würde gerne wissen, ob jemand weiß, was damit nicht stimmt oder mich auf die Antwort verweisen kann.

#include <ncurses.h> 
int main() 
{ 
    initscr(); 
    WINDOW *win = newwin(0,0,10,10); 
    delwin(win); 
    endwin(); 
    return 0; 
} 

== == 20986 Memcheck, ein Speicherfehlerdetektor
== == 20986 Copyright (C) 2002 bis 2013, und GNU GPL, von Julian Seward et al.
== 20986 == Verwenden von Valgrind-3.10.1 und LibVEX; erneut ausführen, mit -h für Copyright-Informationen
== 20986 == Befehl: ./a.out
== 20986 ==
== 20986 ==
== 20986 == HEAP ZUSAMMENFASSUNG:
== 20986 == im Einsatz bei der Ausfahrt: 281.089 Bytes in 193 Blöcken
== == 20986 Gesamt Heap-Verbrauch: 248 Allocs, 55 freigibt, 353.425 Bytes
== == 20986
== == 20986 LEAK ZUSAMMENFASSUNG zugeordnet:
== 20986 == definitiv verloren: 0 Bytes in 0 Blöcken
== 20986 == indirekt verloren: 0 Bytes in 0 Blöcken
== == 20986 möglicherweise verloren: 0 0 Bytes in Blöcken
== == 20986 noch erreichbar: 281.089 Bytes in 193 Blöcken
== == 20986 unterdrückt: 0 Bytes in Blöcken 0
== == 20986 rerun mit --leak-check = alle Einzelheiten durchgesickert Speicher
== 20986 ==
== 20986 == Für Zählungen ermittelt und unterdrückt Fehler, rerun mit, um zu sehen: -v
== 20986 == ERROR ZUSAMMENFASSUNG: 0 Fehler von 0 Kontexten (unterdrückt: 0 von 0)

Danke für Ihre Zeit.

Answer 1

Bibliotheken oft mal Dinge tun, nachdem Ihre int main() beendet ist.

aber sagen, dass ein Beispiel dafür, was passiert, nachdem unter:

#7 0x00007ffff72abfe8 in __run_exit_handlers (status=0, 
    listp=0x7ffff76355f8 <__exit_funcs>, 
    run_list_atexit=run_list_atexit@entry=true) at exit.c:82 
#8 0x00007ffff72ac035 in __GI_exit (status=<optimized out>) at exit.c:104 
#9 0x00007ffff7292837 in __libc_start_main (
    main=0x429e26 <main(int, char**)>, argc=1, argv=0x7fffffffde28, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fffffffde18) at ../csu/libc-start.c:325 
#10 0x0000000000419f69 in _start() 

in einem Beispielprogramm. Die obige Ausgabe wurde von GDB bereitgestellt. Die Relevanz ist jedoch in StackTrace Zeile # 7, Sie sehen einen Teil, der listp=0x7ffff76355f8 sagt; Das ist eine Liste von Funktionsrückrufen, die für die Funktion atexit(); registriert sind. Wahrscheinlich wird alles in ncurses verwendet, und selbst einige der std/stl-Bibliotheken können dort Aufräumarbeiten haben. Im Allgemeinen, oder zumindest, wie ich gelesen habe, kann Valgrind nicht immer diese Ressourcen frei aufnehmen, da die aufrufende Bibliothek ihre Bereinigung verwaltet.

Answer 2

Es ist nichts falsch mit dem angezeigten Code. Es ist normal, dass verschiedene Laufzeitbibliotheken zur Laufzeit Speicher für ihre internen Puffer reservieren, ohne dass sie freigegeben werden, wenn die gemeinsam genutzte Bibliothek entladen wird.

Answer 3

Die Antwort ist in der ncurses FAQ Testing for Memory Leaks:

Vielleicht haben Sie ein Werkzeug verwendet, wie dmalloc oder valgrind für Speicherlecks zu überprüfen. In der Regel wird viel Speicher gemeldet, der noch verwendet wird. Das ist normal.

Die ncurses configure Skript hat eine Option, --disable-leaks, mit dem Sie die Analyse weiterverwenden können. Es teilt Ncurses mit, Speicher freizugeben, wenn möglich. Der größte Teil des verwendeten Speichers ist jedoch "permanent".

Jede Implementierung von Flüchen darf nicht frei der Speicher mit einem Bildschirm verbunden, da (auch nach endwin() Aufruf), ist es für den Einsatz in dem nächsten Aufruf refresh() verfügbar sein muß. Aus Leistungsgründen werden auch Speicherbereiche gespeichert. Das macht es schwierig, Flurs-Anwendungen auf Speicherlecks zu analysieren. Um dies zu umgehen, erstellen Sie eine Debugging-Version der ncurses-Bibliothek, die diese Chunks freigibt und die _nc_free_and_exit()-Funktion bereitstellt, um den Rest beim Beenden freizugeben. Das Dienstprogramm ncurses und test programs verwenden diese Funktion z. B. über das Makro ExitProgram().

Debian, zum Beispiel, bietet Pakete, die zum Testen von Speicherleckstellen nützlich sein könnten: libncurses5-dbg und libncursesw5-dbg.