[C++] String laat geheugen achter? (mtrace)

[Remenic]

Ik heb het volgende stukkie code:

code:

#include <iostream>
#include <string>
#include <mcheck.h>

int main()
{
    mtrace();

    string OS = "GNU/Linux";

    std::cout << OS << endl;
}

Als ik nu mtrace uitvoer op het gegenereerde bestand, dan zie ik:

code:

remenic@sidney:~/projects/mcheck> mtrace m2.mt

Memory not freed:
-----------------
   Address     Size     Caller
0x0804c2f8    0x500  at 0x8049e70

Het maakt niet uit of ik van OS een pointer naar een string maak, en netjes delete als ik er klaar mee ben, of 'em declareer zoals hier boven. In bijde gevallen beweerd mtrace dat er 500(K)B (zijn 't KBytes, of Bytes?) niet vrijgegeven wordt.

Is dit een probleem met mtrace, of met de string class?

Het betreft Linux 2.4.16 met glibc 2.2.4 en gcc 2.95.3.

[Verwijderd]

Ben geen expert ofzo maar ik heb geleerd dat je achter je bibliotheek een '.h' moet typen:

<iostream.h>

[Creepy]

het probleem zou em ook wel eens in de gebruikt includes kunnen zitten..

[Remenic]

Op woensdag 12 december 2001 15:41 schreef Kingetjuh het volgende:
Ben geen expert ofzo maar ik heb geleerd dat je achter je bibliotheek een '.h' moet typen:

<iostream.h>

In het geval van iostream zal dat idd goed gaan, maar string.h en string zijn twee HELE andere bibliotheken.

In C++ eindigen de header files niet altijd met .h. Maar das ook niet altijd zo geweest geloof ik.

[Knoetje]

Was toch iets met malloc ???

[Remenic]

Op woensdag 12 december 2001 15:43 schreef Creepy het volgende:
het probleem zou em ook wel eens in de gebruikt includes kunnen zitten..

als ik <string> include maar verder niet gebruik, dan zijn er geen problemen. 't Gaat echter fout zodra ik een object aanmaak van het type string.

[Remenic]

Let wel, dit lijkt alleen te gebeuren met de string class.

Als ik een char, int*, of zelfs een zelf bedachtte class gebruik, dan werkt 't prima.

[farlane]

En als je een constante string ("Farlane is lief" bijvoorbeeld ) cout?

Ik weet niet hoe mtrace werkt, maar bij gebruik van cout worden wel allerlei statische objecten aangemaakt.

[Orphix]

En als je een string in een loopje zet? Wordt de memory leak dan ook ix groter?

[The End]

Je hebt grote kans dat de memoryleak niet bestaat, maar voor mtrace wel lijkt te bestaan... Als de memory checking routines te vroeg worden aangeroepen, dan lijkt het of er een leak is terwijl die er niet is.
Ik heb dit wel eens gehad in Visual studio met een paar libraries.
Ik zou zeggen: Run het 100000x in een lus en kijk of je prog steeds groter wordt, zoniet dan is het mtrace.

[igmar]

#include <mcheck.h>

int main()
{
mtrace();

string OS = "GNU/Linux";

std::cout << OS << endl;
}[/code]
Als ik nu mtrace uitvoer op het gegenereerde bestand, dan zie ik:

code:

remenic@sidney:~/projects/mcheck> mtrace m2.mt

Memory not freed:
-----------------
   Address     Size     Caller
0x0804c2f8    0x500  at 0x8049e70

Het maakt niet uit of ik van OS een pointer naar een string maak, en netjes delete als ik er klaar mee ben, of 'em declareer zoals hier boven. In bijde gevallen beweerd mtrace dat er 500(K)B (zijn 't KBytes, of Bytes?) niet vrijgegeven wordt.

Neem een andere debug lib. Dat ding snapt geen objects zo te zien. De class OS staat gewoon op de stack, niks mis mee.

[Remenic]

Op woensdag 12 december 2001 16:58 schreef igmar het volgende:

[..]

Neem een andere debug lib. Dat ding snapt geen objects zo te zien. De class OS staat gewoon op de stack, niks mis mee.

Hier ben ik het niet mee eens, want een zelf gemaakte class werkt wel prima.

[Remenic]

Op woensdag 12 december 2001 16:12 schreef Orphix het volgende:
En als je een string in een loopje zet? Wordt de memory leak dan ook ix groter?

Zal ik morgen even testen.


Maar ik denk dat het idd onschuldig is.

[Remenic]

Ik heb net even een loopje gemaakt van 0 tot 10000 (bij 10000000 raakte me HDD vol ), en de memory leak is er niet groter op geworden.

Ik denk dus dat dit een stuk "geshared" geheugen is ofzo, waar de string class gebruik van maakt.

Hoe dan ook, tis "onschuldig"

[The End]

Op donderdag 13 december 2001 08:31 schreef Remenic het volgende:
Ik heb net even een loopje gemaakt van 0 tot 10000 (bij 10000000 raakte me HDD vol ), en de memory leak is er niet groter op geworden.

Ik denk dus dat dit een stuk "geshared" geheugen is ofzo, waar de string class gebruik van maakt.

Hoe dan ook, tis "onschuldig"

Is volgens mtrace niet groter geworden?

[MSalters]

Op woensdag 12 december 2001 15:08 schreef Remenic het volgende:
Ik heb het volgende stukkie code:

code:

#include <iostream>
#include <string>
#include <mcheck.h>

int main()
{
    mtrace();

    string OS = "GNU/Linux";

    std::cout << OS << endl;
}

Als ik nu mtrace uitvoer op het gegenereerde bestand, dan zie ik:

code:

remenic@sidney:~/projects/mcheck> mtrace m2.mt

Memory not freed:
-----------------
   Address     Size     Caller
0x0804c2f8    0x500  at 0x8049e70

Het maakt niet uit of ik van OS een pointer naar een string maak, en netjes delete als ik er klaar mee ben, of 'em declareer zoals hier boven. In bijde gevallen beweerd mtrace dat er 500(K)B (zijn 't KBytes, of Bytes?) niet vrijgegeven wordt.

Is dit een probleem met mtrace, of met de string class?

Het betreft Linux 2.4.16 met glibc 2.2.4 en gcc 2.95.3.

Vrijwel zeker mtrace.

string ofwel std::string werkt met zogenaamde allocators. Een allocator vraagt een groot geheugenblok (aan malloc of new) en verdeelt dat in kleine stukjes voor string (en vector en...) . Het lijkt erop dat mtrace niet doorheeft dat de allocator 0x500 (1280 decimaal) bytes beheert.
Dit is een vrij gangbaar probleem met memory leak detectors.

[drZymo]

Uhm string is een class toch? Als je daar nou eens free() op doet zodat het geheugen zelf wordt vrijgegeven ipv door de compiler. Dan zou het mischien opgelost kunnen zijn.

Correct me if i'm wrong.

Ennu

Op woensdag 12 december 2001 15:46 schreef KNOETJE het volgende:
Was toch iets met malloc ???

Leuk dat je wilt helpen maar hier hebben we nix aan natuurlijk

[Remenic]

Op donderdag 13 december 2001 13:47 schreef drZymo het volgende:
Uhm string is een class toch? Als je daar nou eens free() op doet zodat het geheugen zelf wordt vrijgegeven ipv door de compiler. Dan zou het mischien opgelost kunnen zijn.

Correct me if i'm wrong.

Ennu
[..]

Leuk dat je wilt helpen maar hier hebben we nix aan natuurlijk

Zoals ik al vermeld had, als ik 'm zelf free() of delete (c++), dan zegt mtrace hetzelfde.

[drZymo]

Op donderdag 13 december 2001 15:54 schreef Remenic het volgende:

[..]

Zoals ik al vermeld had, als ik 'm zelf free() of delete (c++), dan zegt mtrace hetzelfde.

oops beter lezen

Denk dan maar zoals de meeste software bedrijven denken: "Wat is nou 500 bytes , we hebben 128 MB gemiddeld in een systeem."

[Olaf van der Spek]

Op donderdag 13 december 2001 13:28 schreef MSalters het volgende:

[..]

Vrijwel zeker mtrace.

string ofwel std::string werkt met zogenaamde allocators. Een allocator vraagt een groot geheugenblok (aan malloc of new) en verdeelt dat in kleine stukjes voor string (en vector en...) . Het lijkt erop dat mtrace niet doorheeft dat de allocator 0x500 (1280 decimaal) bytes beheert.
Dit is een vrij gangbaar probleem met memory leak detectors.

Het zou ook (of waarschijnlijk is) iostream kunnen zijn. Die kan buffers aanmaken.

[MSalters]

Op donderdag 13 december 2001 17:21 schreef OlafvdSpek het volgende:

[..]

Het zou ook (of waarschijnlijk is) iostream kunnen zijn. Die kan buffers aanmaken.

Nee - de OP schreef dat het alleen met string gebeurde, en niet met int. Dat maakt voor de iostream class niet uit, die gebruikt daarvoor dezelfde buffer (std::cout.rdbuf())