[C++]Geheugengebruik van console app loopt op

[styno]

Ik ben bezig met een in C++ geschreven console applicatie (=Win32 DOS scherm). Als de app draait neemt het geheugengebruik per seconde met zo'n 4k toe. Nou heb ik met CrtMemDifference gezocht waar eventueel een geheugenlek in de code zit, maar deze vindt er geen.

Het aparte is dat het (extra) gealloceerde geheugen weer vrijgegeven wordt op het moment dat het venster geminimaliseerd wordt. Direct daarna begint het geheugengebruik weer op te lopen. Dit gebeurt zowel in debug al in de release versie. Ik denk dat het dan ook niet aan het programma ligt, maar waaraan dan wel

Ik gebruik Windows 2000 Sp2, Visual Studio 6 en er wordt niks naar het beeldscherm geschreven, ook gebruik ik (nog) geen console buffers.

Iemand een idee?

[LordLarry]

Windows is je aan het foppen. Kijk niet naar de Mem. Usage., maar naar de VM Size en kijk of je er dan noch last van hebt. Het waarom heb ik al teveel keer uitgelegd hier

[styno]

Ok, hebbik gedaan: Ook de VM Size loopt op, maar wanneer ik de applicatie minimaliseeer dan wordt het teveel gealloceerde geheugen bij Mem Usage weer vrijgegeven, maar bij VM Size blijft deze gewoon oplopen.

[Verwijderd]

Toch een memleakje tip download een trial versie van purify wedde dat je 'm in notime genailed hebt dan

[Verwijderd]

Volgens mij is het maar de vraag of bij het minimaliseren precies het teveel gealloceerde geheugen wordt vrijgegeven. Ik heb zelf ook al eens geconstateerd dat als je minimaliseert, er circa 1.5MB wordt vrijgegeven. Maar dat gebeurt ook bij programma's die absoluut NIET lekken. Als je daarna weer maximaliseert, komt die 1.5MB er overigens NIET meteen weer bij. Als je't mij vraagt lijkt het erop dat er de nodige troep die maar eenmalig nodig is, pas wordt opgeruimd bij minimaliseren....

Niet dat je hier heel veel aan hebt voor het opsporen van je lek, trouwens.

[styno]

Verwijderd schreef op 02 september 2002 @ 14:08:
Toch een memleakje tip download een trial versie van purify wedde dat je 'm in notime genailed hebt dan

Ga ik maar es ff doen, bedankt.

Ik heb zelf ook al eens geconstateerd dat als je minimaliseert, er circa 1.5MB wordt vrijgegeven. Maar dat gebeurt ook bij programma's die absoluut NIET lekken.

Als ik lang genoeg wacht, en het programma heeft al rond de 40 meg gealloceerd dan wordt dit ook allemaal vrijgegeven.

Als je daarna weer maximaliseert, komt die 1.5MB er overigens NIET meteen weer bij.

Klopt dat heb ik hier ook, maar wel komt er elke seconde zo rond de 4k bij, maar dat kan, zoals YarVieh het opmerkt, misschien met Rational Purify opgelost worden.

[Verwijderd]

Je kan ook boundschecker van compuware(numega) nemen, maar die heeft zover ik weet geen trial versie en is imho iets minder stabiel als purify (heb wel es dat apps crashen op vage boundschecker dlls)

[Verwijderd]

Er is hier toch iets wat mij volledig ontgaat ...
Minimalizeren is niets anders dan een je window verbergen. Oftewel paint acties op de DC van je window worden niet op het scherm getoont. Dat heeft toch niets met geheugen te maken (niet direct althans). Dus of jouw programma of windows is HEEL ERG brak.

Is het niet mogelijk om een wrapper functie om de alloc/free functies te bouwen, waarin je alles logt. (alloc = ++, free = --) Zo weet je exact hoeveel jouw programma verbruikt.

Het probleem hierbij is dat het heel leukt werkt als je overal consequent alloc/free gebruikt en het wat lastiger word met new delete. (don't use object oriëntated languages anyway).

[Verwijderd]

Er is hier toch iets wat mij volledig ontgaat ...Minimalizeren is niets anders dan een je window verbergen.

Ehh schijnbaar past de NT kernel als je je app minimized de working set size aan, zie Inside windows 2000 voor een uitgebreide beschrijving over de werking van de Virtual Memory Manager gezien dit imho te complex is om in 'n topicje op got uit te leggen.

[.oisyn]

Verwijderd schreef op 02 september 2002 @ 20:05:
Het probleem hierbij is dat het heel leukt werkt als je overal consequent alloc/free gebruikt en het wat lastiger word met new delete. (don't use object oriëntated languages anyway).

new en delete kun je ook gewoon overloaden
en waarom zou je geen OO moeten gebruiken? Kun je dat eens onderbouwen?

[Verwijderd]

Mjah, unteraarsch vindt ook dat je geen comments in je proggen moet zetten... Imho houdt hij er nogal dwarse meningen op na. Niets persoonlijks overigens, ieder zijn meug...

[MSalters]

Verwijderd schreef op 02 september 2002 @ 20:05:
Er is hier toch iets wat mij volledig ontgaat ...
Minimalizeren is niets anders dan een je window verbergen. Oftewel paint acties op de DC van je window worden niet op het scherm getoont. Dat heeft toch niets met geheugen te maken (niet direct althans). Dus of jouw programma of windows is HEEL ERG brak.

Is het niet mogelijk om een wrapper functie om de alloc/free functies te bouwen, waarin je alles logt. (alloc = ++, free = --) Zo weet je exact hoeveel jouw programma verbruikt.

Het probleem hierbij is dat het heel leukt werkt als je overal consequent alloc/free gebruikt en het wat lastiger word met new delete. (don't use object oriëntated languages anyway).

Jammer maar helaas. malloc/free mag je niet vervangen in C. In C++ mag je operator new/ operator delete wel vervangen.

Bedoelde je niet "I don't use object oriented languages anyway" ?

[ Voor 0% gewijzigd door MSalters op 04-09-2002 14:56 . Reden: Smiley doet't niet voor "Jammer" ]

[styno]

Allemaal heel erg bedankt, het bugje (was toch mijn fout) was dat in de destructor van mijn CMutex class PThreads niet ge-deinit werd.

Toch raar trouwen dat functies als CrtMemDifference dit soort problemen blijkbaar niet op kunnen sporen. Rational Purify was in dit geval de oplossing: het geeft zelfs de regel aan waarop het geheugenlek optreedt, echt ideaal.

Ik ben nog niet zo lang geleden van C naar C++ overgestapt en ik zie een heleboel mogelijkheden om de code gestructureerder in te kloppen, ik snap dan ook niet wat Unteraarsch hier tegen heeft. BTW ik wil hierover geen discussie starten het is gewoon een opmerking.

[curry684]

Verwijderd schreef op 02 september 2002 @ 20:05:
Is het niet mogelijk om een wrapper functie om de alloc/free functies te bouwen, waarin je alles logt. (alloc = ++, free = --) Zo weet je exact hoeveel jouw programma verbruikt.

Tuurlijk is dat mogelijk, heel gangbaar zelfs... en je hebt ook nog IMallocSpy als je via Win32/COM werkt

Het probleem hierbij is dat het heel leukt werkt als je overal consequent alloc/free gebruikt en het wat lastiger word met new delete.

Ach...

code:

inline void* operator new(size_t p_Size)       { return MyAllocRoutine(p_Size); }
inline void* operator new [] (size_t p_Size)   { return MyAllocRoutine(p_Size); }
inline void operator delete(void* p_Block)     { MyReleaseRoutine(p_Block); }
inline void operator delete [] (void* p_Block) { MyReleaseRoutine(p_Block); }

[.oisyn]

het is alleen wat vervelend dat die operatoren alleen in de huidige namespace werken (en natuurlijk in namespaces die de operatoren uit de huidige namespace gebruiken )

maar aan de andere kant: een andere namespace is meestal een bepaalde library oid... en daarvan mag je wel verwachten dat de boel niet lekt

[Verwijderd]

Weliswaar volledig off-topic, maarrr:

.oisyn schreef op 02 september 2002 @ 21:47:
new en delete kun je ook gewoon overloaden
en waarom zou je geen OO moeten gebruiken? Kun je dat eens onderbouwen?

De enige onderbouwing die ik heb is de volgende:
Ik ben ooit een projectje begonnen in c++, was aardig aan het lukken. Maar ik was heel erg aan het kutten met de stijl. Toen ben ik (vraag niet waarom) de source gaan herschrijven zonder classes/methodes, maar met structs/functions. De source werd echt twee keer zo klein en deed precies hetzelfde.
Geen gekut met set_value/get_value functies maar gewoon de struct member een waarde geven. Klaar.
Ik heb niets tegen het idee van objecten, maar ik kan niet tegen code die niets uitvoerd maar alleen conventie is. Gewoon niet mijn stijl.

[TheMrH]

Maar in die set en get methodes kan je allerlei checks uitvoeren. Is de gesette var wel binnen een bepaalde range, mag je wel setten in de huidige state van het object, misschien moet er na die set nog het eea intern worden geinitialiseerd/ingesteld/veranderd. Ook is het handig met debuggen, je kan precies zien wie er waneer wat inzet.
Volgens mij optimaliseerd de compiler tegenwoordig zover dat je bijna een struct achtig iets overhoudt, dus voor de snelheid hoef je het ook niet echt te doen.

Waneer je puur en alleen wat simpele data op wilt slaan en beschikbaar wilt hebben kan je natuurlijk zo'n eigen struct en functies methode gebruken. Mijn ervaring leert mij dat dat soort dingen meestal uitgroeien, en dan wordt het alsnog omschrijven

[.oisyn]

unteraarsch: is dat je reden? pffff...

dat jij niet snapt waarvoor data hiding en encapsulation is, is nog geen reden om andere mensen af te raden OO te coden... vind het een beetje loos argument eigenlijk

[Zoijar]

TheMrH schreef op 04 september 2002 @ 22:06:
Waneer je puur en alleen wat simpele data op wilt slaan en beschikbaar wilt hebben kan je natuurlijk zo'n eigen struct en functies methode gebruken. Mijn ervaring leert mij dat dat soort dingen meestal uitgroeien, en dan wordt het alsnog omschrijven

Soms wil je wel nog steeds basic structs gebruiken (ofwel POD types, plain old data types) Dit vanwege de standaard garantie dat POD types gekopieerd kunnen worden via een memcopy ter grote van sizeof(POD). Dat is wel handig als je bv packets naar een netwerk kaart memory mapped IO wilt dumpen.

[Verwijderd]

.oisyn schreef op 04 september 2002 @ 22:16:
unteraarsch: is dat je reden? pffff...

dat jij niet snapt waarvoor data hiding en encapsulation is, is nog geen reden om andere mensen af te raden OO te coden... vind het een beetje loos argument eigenlijk

.oisyn, jij bent toch moderator?? dan moet je dit topic toch dichtgooien omdat het nogal off-topic gaat en mensen teveel met hun mening gaan rondbazuinen?

edit: Ik hoop dat je snapt dat ik niet bedoelde dat mensen niet OO moeten gaan proggen (heb ik ook een lange periode gedaan), maar dat ik er het voordeel niet zo van in zie.

[.oisyn]

Verwijderd schreef op 05 september 2002 @ 00:35:
[...]

.oisyn, jij bent toch moderator?? dan moet je dit topic toch dichtgooien omdat het nogal off-topic gaat en mensen teveel met hun mening gaan rondbazuinen?

er is niets mis met offtopic gedrag (zolang het nog maar met P&W te maken heeft), en als je hier je mening niet mag geven dan ontgaat het nut van een forum me even...

edit: Ik hoop dat je snapt dat ik niet bedoelde dat mensen niet OO moeten gaan proggen (heb ik ook een lange periode gedaan), maar dat ik er het voordeel niet zo van in zie.

ah ok, zo kwam het wel over... misverstand dus . Ik heb er natuurlijk totaal geen problemen mee dat jij ervoor kiest om niet OO te coden, maar dan moet je niet zeggen tegen anderen dat ze het niet moeten doen, zonder zinnige onderbouwing (maar dat bedoelde je dus niet)

[curry684]

.oisyn schreef op 04 september 2002 @ 20:52:
het is alleen wat vervelend dat die operatoren alleen in de huidige namespace werken (en natuurlijk in namespaces die de operatoren uit de huidige namespace gebruiken )

maar aan de andere kant: een andere namespace is meestal een bepaalde library oid... en daarvan mag je wel verwachten dat de boel niet lekt

Sowieso doe je het meestal zo:

C++:

class MyBaseObject
{
public:   // Methods
  ...
  
  void*             operator new(size_t p_Size);
  void              operator delete(void* p_Block);
};

Zodat je niet iedere boerenlul met jouw alloc routines opscheept maar alleen objecten uit je eigen classtree.

[.oisyn]

curry684 schreef op 05 september 2002 @ 02:38:
[...]

Sowieso doe je het meestal zo:

C++:

class MyBaseObject
{
public:   // Methods
  ...
  
  void*             operator new(size_t p_Size);
  void              operator delete(void* p_Block);
};

Zodat je niet iedere boerenlul met jouw alloc routines opscheept maar alleen objecten uit je eigen classtree.

Dat werkt anders dan new en delete operatoren in een namespace definieren. Als jij new en delete operatoren in een namespace definieert en je gebruikt die operatoren in je eigen klassen, dan worden alle allocaties en deallocaties met je eigen routine gedaan. Iemand die van buiten de namespace een instantie van een van jou klassen aanmaakt gaat niet via die new en delete operatoren (tenzij je ze used natuurlijk )

Als je new en delete operatoren in een klasse definieert dan werkt het precies andersom: allocaties binnen de klasse gaan via de reguliere new/delete operatoren en als mensen die jouw klasse instantieren met new dan wordt de new operator van jouw klasse aangeroepen

^{PS. check je mail}

[MSalters]

Zoijar schreef op 04 september 2002 @ 23:15:
[...]


Soms wil je wel nog steeds basic structs gebruiken (ofwel POD types, plain old data types) Dit vanwege de standaard garantie dat POD types gekopieerd kunnen worden via een memcopy ter grote van sizeof(POD). Dat is wel handig als je bv packets naar een netwerk kaart memory mapped IO wilt dumpen.

Dat werkt dus niet betrouwbaar. PODs hebben geen vastgelegde padding. Je kunt ze dus wel veilig naar een andere POD met dezelfde layout kopieren (lees: naar object met hetzelfde type) maar niet noodzakelijkerwijs naar HW met fixed layout.
(Of bedoel je dat je aan de andere kant v/h netwerk jouw programma ze dan veilig van het netwerk in zo'n POD kan kopieren? Dat werkt natuurlijk wel).

Overigens heeft class vs. struct niets met POD-ness te maken. struct{ is gewoon een korte maniet om class{public: te schrijven.

[curry684]

.oisyn schreef op 05 september 2002 @ 17:33:
in een klasse definieert dan werkt het precies andersom: allocaties binnen de klasse gaan via de reguliere new/delete operatoren en als mensen die jouw klasse instantieren met new dan wordt de new operator van jouw klasse aangeroepen

Wat juist handig is zodat je alleen leaks controleert van je eigen framework en niet eventuele (wellicht bedoelde!) leaks van andere classes...

^{PS. check je mail}

Uh okay