Hat std::cout ein memory leak?

 - (Computer, Programmieren, Informatik)

1 Antwort

Vom Fragesteller als hilfreich ausgezeichnet

Nein, das ist (IMHO) nicht normal. In C sind die Puffer von FILE auf Bibliothekebene z.B. 1K oder 8K und statisch. BEim eigentlichen Konsolentreiber wird es ähnlich sein.

cout ist ja im Endeffekt nur ein std::basic_ostream, oder irre ich mich da gerade?

https://en.cppreference.com/w/cpp/io/cout

Sagt dem ist so.

ich mache aber nichts, außer eine Zeile auskommentieren, wo ein cout drin ist.

0
@michiwien22

Interessant, also std::basic_streambuf scheint nichts anderes als eine Ringpufferimplementierung zu sein, wenn ich mir die Schnittstelle so anschaue. ich müßte jetzt natürlich in eine konkrete Implementierung der Bibliothek rainschauen.

Andererseits wird std::cout an den normalen stdout gebunden udn synchronisiert. Da dieser nicht dynamisch wächst, wäre das sehr eigentartig.

Vielleicht sorgt einer der übergebenen Parameter indeirekt für einen Leak, hast Du mal mit valgrind draufgeschaut?

1
@KarlRanseierIII

Der Parameter ist es nicht. Es ist nur

std::cout << "from queue: message received" << std::endl;

Tu ich das weg, geht es.

0
@michiwien22

Okay, der const liegt im bss, der kann nicht Schuld sein. Die Zeile für sich genommen kann auch kaum eine Stack- oder Heap-Korruption verursachen.

Es findet keine Allokation statt.

Und der Wert steigt definitiv mit jedem Call an std::cout?

------

Wenn es ganz blöde läuft ist die Zeile nur ein mittelbarer Auslöser - sowas ist dann sehr schwer zu finden.

1
@KarlRanseierIII

>Und der Wert steigt definitiv mit jedem Call an std::cout?

ja, ich starte mit 1Mbyte und ende nach einer halben Stunde mit 1000Mbyte. Sonst nichts geändert - Tatsache! Ohne diese eine Zeile bleine ich stundenlang bei 1MByte.

Läuft unter Visual Studio 2019.

0
@michiwien22

Gibt es da eine Art mem-profiler wie valgrind, mit dem man Memleaks aufspüren kann?

----

Gib es zu, DU hast ne magische Box gebaut! ;-).

1
@michiwien22

Kann ich nachvollziehen.

Es gibt ja eigentlich ur zwei Möglichkeiten:

Irgendwo anders wird etwas versaubeutelt, daß sich durch die Ausgabe erst manifestieren kann, oder es wäre ein Bug in der Standardbibliothek die bei Deinem Compiler dabei ist (Alternativ ein Bug im Compiler, der durch den Code der Standardbibliothek ausgelöst wird). Wäre bei so einen Basissache aber doch recht erstaunlich.

Passiert das Ganze denn auch, wenn Du ein Minimalbeispiel baust? Das wäre vielleicht auch interessant.

Denn wenn Du es isolieren kannst, kann man mit Schuldzuweisungen beginnen.

1
@KarlRanseierIII

Hab ich noch nicht ausprobiert. Ich verwende boost::asio zusammen mit eigenen Template Klassen. Die Ausgabe erfolgt in jeweils einem Worker-Thread; davon habe ich 10.

0
@michiwien22

Ich konnte inzwischen herausfinden, daß VS unter Windows anscheinend cout nicht preallokiert, sondern nur bei (erster) Verwendung allokiert wird.

Ich überlege gerade, ob hier vielleicht etwas nicht richtig reentrant ist.

1
@KarlRanseierIII

Also laut MS-Doku sollte cout Thread-Safe sein, die Ausgaben können zwar intermixed werden, der innere Zustand soll aber konsistent bleiben.

Hier könnte man natürlich auch testen, ob man die cout mit einer eigenen mutex schützt, und schaut, ob dann das 'leaken' aufhört - Das wäre dann wirklich ein Indikator, daß die thread-safety doch nicht richtig gegeben ist.

Für alles andere muß man eben weiter in den Code schauen, oder eben Leak Detection nutzen.

Eventuell kommst Du hiermit weiter:

https://docs.microsoft.com/de-de/visualstudio/debugger/finding-memory-leaks-using-the-crt-library?view=vs-2019

0

Was möchtest Du wissen?