STL mem leak?

04/23/2012 06:49 Tyrar#1
ist es möglich, dass die stl nen memory leak verursachen kann?

ich habe meine eigene buffer klasse, die per ref counter kontrolliert wird. der speicher der buffer wird auch freigegeben (alles mit geloggt)

könnte es daran liegen, dass z.b. std::string immer kopiert wird?
Code:
void foo()
{
    std::string x("abcd");
    bar(x);
}

void bar(std::string x)
{
    std::cout << x << std::endl;
}
oder hängt das einfach nur mit der crt zusammen?
mein bot (ja das soll ein bot werden) soll möglichst nicht wegen so einem grund crashen.
hab meinen code nur ca. 1 minute laufen lassen, ist es evtl. normal, dass bis zu einer bestimmten menge allokiert wird es aber später dabei bleibt?

sinnvoll in dem fall meine eigenen wrapper klassen zu schreiben?
04/23/2012 13:19 MrSm!th#2
Ich versteh die Problemstellung nicht oO
Was meinst du? Du allozierst in einer Schleife mehrmals einen String und trotz Freigabe ist am Ende der Schleife mehr Speicher in Benutzung als vorher?
Was gibst du frei? std::string gibt den Speicherplatz doch automatisch im Destruktor frei.
04/23/2012 14:51 Tyrar#3
Quote:
Originally Posted by MrSm!th View Post
Ich versteh die Problemstellung nicht oO
Was meinst du? Du allozierst in einer Schleife mehrmals einen String und trotz Freigabe ist am Ende der Schleife mehr Speicher in Benutzung als vorher?
Was gibst du frei? std::string gibt den Speicherplatz doch automatisch im Destruktor frei.
das problem ist, dass der gesamte speicher den ich mit new/malloc allokiere auch wieder freigegeben wird!
1 loop -> ~800k
30 -> ~1200k

Code:
std::map<uint32_t, std::string> foo;
for(uint32_t bar=0; bar<32; ++bar) foo[bar]=std::string("abcdefg");
foo.clear();
wenn ich das wiederholen würde (in einer func), würde ich am ende immernoch mehr speicher verwenden als es vorher war :|
wie gesagt, ich weiss nicht ob es bis zu einer bestimmten menge normal ist
04/23/2012 15:08 Nightblizard#4
Ich wage sehr zu bezweifeln, dass die STL ein Speicherloch hat.
Ich schätze der Grund dafür ist einfach, dass der freigegebene Speicher erst ab einer gewissen Größe zurück an das System gegeben wird.
Außerdem würde es mich doch sehr interessieren wie du das Ganze genau verwendest, da du vielleicht einfach nur an der falschen Stelle schaust (vorallem wenn du im Release Modus kompilierst kannst du nicht wissen wann der Speicher freigegeben wird).

Also nein, in der STL ist garantiert kein memory leak! Das hätte schon jemand lange vor dir gemerkt. :P
04/23/2012 15:41 Tyrar#5
Code:
class CBotCore
{
private:
    std::map<uint8_t,PacketHandler_t> m_packetHandlers;
    std::vector<CBotConfig*> m_configs;
    std::string m_name;
}
Code:
CBotCore::CBotCore(std::string name) : m_name(name) { };
CBotCore::~CBotCore()
{
    this->m_packetHandlers.clear();
    for(std::vector<CBotConfig*>::iterator it=this->m_configs.begin(); it!=this->m_configs.end(); ++it) {
        CBotConfig* cfg=*it;
        if(cfg==nullptr)
            continue;
        cfg->Cleanup();
        delete cfg;
    }
    this->m_configs.clear();
}
die anderen klassen sehen so ähnlich aus, sind nur mehr oder weniger stl container :|
04/23/2012 18:12 Nightblizard#6
Hmm, keine Ahnung wann das dann freigegeben wird. Aber ein Leak ist es definitiv nicht, das hätte man schon vor vielen Jahren entdeckt!

Btw. gibt es einen Grund warum du kein auto nutzt?
for(auto it = this->m_configs.begin(); ...)
Das ist deutlich angenehmer zu schreiben. :P
Noch besser wäre sogar std::for_each, aber das hat mit dem Problem nichts am Hut. :)
04/23/2012 18:19 MrSm!th#7
Ich dachte mit C++11 wäre ein natives foreach Statement dazugekommen :<
04/23/2012 18:50 Nightblizard#8
Jau, aber das kann VS10 noch nicht.
for(auto& i : myIntVector)
{
std::cout << i << std::endl;
}
04/24/2012 00:16 Tyrar#9
ich bin nen gcc user, kann mir für crossplattform coding die eigenschaften eines windows compilers nich erlauben :D

mir ist grade aufgefallen, dass wahrscheinlich das std::map objekt nicht gelöscht wird :|

der gesamte speicher der durch die strings belegt wird, wird wieder freigegeben -> der vom map objekt bleibt und wird neu allokiert :|

damit hätte ich zwar jetzt kein riesen problem, der wichtigste teil des codes is inzwischen eh in asm nach gecoded (mehr performance kann nicht schaden)..
der c++ teil wird dann wohl etwas anders geschrieben, dass ich möglichst das map objekt nur einmal allokieren muss.

wären ref. parameter sinnvoll?

edit: hab grad ne halbe stunde laufen lassen, start 320k direkt auf 732k hoch und dabei bleibts (alles schön mit while(botCore.Run()); getestet, im prinzip == while(1))
04/24/2012 13:18 Nightblizard#10
Quote:
Originally Posted by HeavyHacker View Post
ich bin nen gcc user, kann mir für crossplattform coding die eigenschaften eines windows compilers nich erlauben :D
Kann der gcc nicht sogar mehr als der Windows Compiler?
[Only registered and activated users can see links. Click Here To Register...]
Welche Version nutzt du?

Habe das Teil noch nie genutzt, deshalb weiß ich leider nicht viel darüber.
Quote:
Originally Posted by HeavyHacker View Post
mir ist grade aufgefallen, dass wahrscheinlich das std::map objekt nicht gelöscht wird :|

der gesamte speicher der durch die strings belegt wird, wird wieder freigegeben -> der vom map objekt bleibt und wird neu allokiert :|
Merkwürdig. Hat der gcc vielleicht eine Macke? Vielleicht solltest du dich dahingehend mal umhören.
Ich denke wir übersehen hier einfach irgendwas. :/
Quote:
Originally Posted by HeavyHacker View Post
damit hätte ich zwar jetzt kein riesen problem, der wichtigste teil des codes is inzwischen eh in asm nach gecoded (mehr performance kann nicht schaden)..
Nur weil etwas in Assembly geschrieben wurde, ist es nicht auch gleich schneller. std::map garantiert eine Zugriffsgeschwindigkeit von O(ln(n)), das zu erreichen wird schwer und zu toppen fast unmöglich.
Quote:
Originally Posted by HeavyHacker View Post
der c++ teil wird dann wohl etwas anders geschrieben, dass ich möglichst das map objekt nur einmal allokieren muss.

wären ref. parameter sinnvoll?
Inwiefern? Ohne move semantics aus C++11 sind die durchaus sinnvoll!

Doch die Frage sollte eher lauten "ist std::map wirklich notwendig".
Das ist ein sehr spezialisierter Container und ein einfacher Vector ist in den meisten Fällen die bessere Wahl.
Deine Implementation schaut so aus, als würdest du ihn in etwa so verwenden:
Code:
void Foo::handlePacket(const Packet& packet)
{
	m_packetHandlers[packet.Id].handlePacket(packet);
}
Liege ich da richtig? Sollte die Paketnummer periodisch weiterlaufen, dann würde es sich anbieten einen Vector zu nutzen.
Code:
/*Angenommen die Pakete sind von 10 aufwärts durchnummeriert*/
void Foo::handlePacket(const Packet& packet)
{
	/*std::vector<PacketHandler_T> m_packetHandlers(numPacketHandlers);*/
	m_packetHandlers[packet.Id - 10].handlePacket(packet);
}
04/24/2012 15:29 Tyrar#11
Quote:
Originally Posted by Nightblizard View Post
Kann der gcc nicht sogar mehr als der Windows Compiler?
[Only registered and activated users can see links. Click Here To Register...]
Welche Version nutzt du?

Habe das Teil noch nie genutzt, deshalb weiß ich leider nicht viel darüber.

Merkwürdig. Hat der gcc vielleicht eine Macke? Vielleicht solltest du dich dahingehend mal umhören.
Ich denke wir übersehen hier einfach irgendwas. :/
habe auch das gefühl dass einfach mein gcc etwas spinnt, in meinem letzten thread hatte ich auch das problem, dass die for loop einfach nicht endet (uint8_t<32, zählt aber bis 255 und fängt natürlich wieder bei 0 an)

ich verwende aktuell 4.6.3, ich werde erstmal auf 4.7.0 updaten
Quote:
Originally Posted by Nightblizard View Post
Nur weil etwas in Assembly geschrieben wurde, ist es nicht auch gleich schneller. std::map garantiert eine Zugriffsgeschwindigkeit von O(ln(n)), das zu erreichen wird schwer und zu toppen fast unmöglich.
ich habe hier eher von den funktionen gesprochen, die ziemlich oft gecalled werden -> encrypt/decrypt..
ohne lokale variablen sind die definitiv performanter, alles läuft direkt über die register!
Quote:
Originally Posted by Nightblizard View Post
Inwiefern? Ohne move semantics aus C++11 sind die durchaus sinnvoll!

Doch die Frage sollte eher lauten "ist std::map wirklich notwendig".
Das ist ein sehr spezialisierter Container und ein einfacher Vector ist in den meisten Fällen die bessere Wahl.
Deine Implementation schaut so aus, als würdest du ihn in etwa so verwenden:
Code:
void Foo::handlePacket(const Packet& packet)
{
	m_packetHandlers[packet.Id].handlePacket(packet);
}
Liege ich da richtig? Sollte die Paketnummer periodisch weiterlaufen, dann würde es sich anbieten einen Vector zu nutzen.
Code:
/*Angenommen die Pakete sind von 10 aufwärts durchnummeriert*/
void Foo::handlePacket(const Packet& packet)
{
	/*std::vector<PacketHandler_T> m_packetHandlers(numPacketHandlers);*/
	m_packetHandlers[packet.Id - 10].handlePacket(packet);
}
ja ähnlich, ich hab mich allerdings inzwischen für nen function pointer array entschieden (PacketHandler_t m_packetHandlers[0xFF])
in dem fall ist das sogar besser, da ich dann immer für jedes packet eine funktion habe (default handler)
04/24/2012 18:54 MrSm!th#12
unterschätz compiler nicht, die generieren größtenteils intelligenteren code und register kann der natürlich auch nutzen.
04/24/2012 21:45 Tyrar#13
Quote:
Originally Posted by MrSm!th View Post
unterschätz compiler nicht, die generieren größtenteils intelligenteren code und register kann der natürlich auch nutzen.
glaub mir, in dem fall is mein code minimal effektiever :)
ausserdem hat das noch nen anti debugging vorteil (zumindest in dem fall)

und mit ner aktuelleren version läufts auch ohne probleme..
total strange :confused:
04/24/2012 22:35 MrSm!th#14
Quote:
glaub mir, in dem fall is mein code minimal effektiever
Bezweifel ich. Nimms mir nicht böse, aber da arbeiten Leute an solchen Compilern, die haben schon in ASM programmiert, bevor du geboren wurdest. Die wissen, wie man effizienten Code generieren lässt, zumal ein Programm das ganze halt effizienter und in komplexeren Vorgängen machen kann, ohne etwas zu übersehen.
Ich bin sicher, ein auf Laufzeit optimierter Compiler liefert mindestens genau so guten Code.
Die Frage wäre aber eher: Who the fuck cares? Diese paar 1/100 Nanosekunden interessieren keinen. Ich bezweifle, dass dein Bot diesen Geschwindigkeitsschub braucht.
Wenn du gerne in ASM programmierst, ok, bleibt dir überlassen, aber bitte bringt nicht so nen Blödsinn wie "Es bringt mehr Performance".

Quote:
und mit ner aktuelleren version läufts auch ohne probleme..
total strange
Dann lag wohl ein Fehler in deiner gcc Installation vor.
04/24/2012 22:55 Tyrar#15
Quote:
Originally Posted by MrSm!th View Post
Bezweifel ich. Nimms mir nicht böse, aber da arbeiten Leute an solchen Compilern, die haben schon in ASM programmiert, bevor du geboren wurdest. Die wissen, wie man effizienten Code generieren lässt, zumal ein Programm das ganze halt effizienter und in komplexeren Vorgängen machen kann, ohne etwas zu übersehen.
Ich bin sicher, ein auf Laufzeit optimierter Compiler liefert mindestens genau so guten Code.
Die Frage wäre aber eher: Who the fuck cares? Diese paar 1/100 Nanosekunden interessieren keinen. Ich bezweifle, dass dein Bot diesen Geschwindigkeitsschub braucht.
Wenn du gerne in ASM programmierst, ok, bleibt dir überlassen, aber bitte bringt nicht so nen Blödsinn wie "Es bringt mehr Performance".

Dann lag wohl ein Fehler in deiner gcc Installation vor.
der minimale performance schub ist in dem fall natürlich nicht nötig, dient aber nem kleinen crack schutz :)

der code wurde übrigens vom compiler auf runtime optimiert.. ich habe da nur noch ein wenig mehr optimiert, da stimme ich dir zu, compiler hauen schon extrem guten code raus. :)

naja, das problem hat sich erledigt, hier könnte geclosed werden ;)