Geheugenlek-meet-prog

[Verwijderd]

Ik heb een programma geschreven in een programmeertaal en nu zou ik op een vrij 'makkelijke' manier willen nagaan of er niet ergens een geheugenlek zit. Noteren hoeveel bytes vrij geheugen ik heb onder Windows XP, het programma runnen en afsluiten en kijken hoeveel bytes vrij geheugen ik daarna over heb is waarschijnlijk niet de manier.

Heeft iemand anders een idee?

[Verwijderd]

Op zaterdag 13 april 2002 15:31 schreef Aegis het volgende:
Ik heb een programma geschreven in een programmeertaal

Wil je nog vertellen *WELKE* of zeg je van nou nee ik heb niet echt gerichte hulp nodig...

[Sponge]

Taal?

Anyway, gebruik GlobalMemoryStatus API om het geheugen van te voren te meten, en er na.. zie je wat er ontbreekt

Natuurlijk moet je dan geen andere programma's draaien die ook steeds extra geheugen aanvragen, bijv. zoals een MP3 speler ofzo... Je kunt uiteraard ook gewoon een of andere performance monitor gebruiken die je vast wel vindt op tucows.com/download.com (of ctrl-alt-del->process list in Win2k/NT)

Trouwens, vaak blijft het programma toch nog in het geheugen, als je bijv Unreal Tournament ziet..eerste keer opstarten kost een halve minuut..2de keer ongeveer 5 seconden...

[Verwijderd]

Op zaterdag 13 april 2002 15:32 schreef Yarvieh het volgende:

[..]

Wil je nog vertellen *WELKE* of zeg je van nou nee ik heb niet echt gerichte hulp nodig...

Het is een programmaatje voor eigen gebruik. Executable is ongeveer 300 kb, geschreven in Delphi 6. Ik weet niet wat voor meer *GERICHTE* informatie je nodig hebt?

edit:

Oh, niet gezien dat er alweer iemand had wat gepost. Is er geen shareware of freeware programmaatje die zoiets kan doen?

[Verwijderd]

Op zaterdag 13 april 2002 15:31 schreef Aegis het volgende:
het programma runnen en afsluiten en kijken hoeveel bytes vrij geheugen ik daarna over heb is waarschijnlijk niet de manier.

Als je een programma afsluit gebruikt die 0 bytes geheugen.

[Verwijderd]

Op zaterdag 13 april 2002 15:37 schreef Aegis het volgende:
Ik weet niet wat voor meer *GERICHTE* informatie je nodig hebt?

Taal was idd erg handig geweest, aangezien je memory leaks op exe files vrij slecht kan detecten (je ziet dat ie na een X aantal uur flink wat gehuegen gebruikt maar wie weet is dat wel terrecht) wat je nodig hebt is een tool die bij je source al bij houd waar je geheugen alloceerd en wanneer en of het weer vrij gegeven word, numega boundschecker is zo'n tool kost je alleen een paar centen, je kan natuurlijk ook zelf 'n wrappertje om je geheugen alloceer/vrijgeef routines proggen.

[Verwijderd]

Op zaterdag 13 april 2002 15:41 schreef deur het volgende:

[..]

Als je een programma afsluit gebruikt die 0 bytes geheugen.

Sorry Deur, maar volgens mij is de definitie van een geheugenlek, dat na het afsluiten van het programma niet alle het geheugen wat door het programma gebruikt/gealloceerd is, weer vrijgegeven wordt. Bepaalde dingen blijven dus in het geheugen staan. Ik zeg niet zo dat dat zo is bij m'n programma, maar daar zou ik dus graag op willen controleren.

[Verwijderd]

Op zaterdag 13 april 2002 15:44 schreef Aegis het volgende:
Sorry Deur, maar volgens mij is de definitie van een geheugenlek, dat na het afsluiten van het programma niet alle het geheugen wat door het programma gebruikt/gealloceerd is, weer vrijgegeven wordt.

Bij het afsluiten van een process wordt al het gealloceerde geheugen door het operating systeem vrij gegeven.

[Sponge]

Op zaterdag 13 april 2002 15:41 schreef deur het volgende:

[..]

Als je een programma afsluit gebruikt die 0 bytes geheugen.

Absoluut niet waar... er kunnnen nog bitmaps/Dc's in het geheugen blijven, hooks/subclassing kunnen dingen behoorlijk verzieken. Vooral als de runtime geen garbage collection heeft, meestal neemt Windows het ook wel over voor wat dingen, zoals DC's... Daaorm moet je in theorie elk object ook op Nothing zetten, elke form nothing maken, etc. Zelf gebruik ik geen Delphi, maar VB, maar het principe blijft hetzelfde.

Volgens mij zijn er maar twee talen die een echte garbage collection hebben, JAVA en .Net

Ik zal ff kijken of ik een simpel geheugen prog kan vinden... Als je niet Win2k of NT4 hebt, is er toch ook zo een soort programma in Win98/95, etc? ( onder Accessories, System tools ofzo??)

Edit:
Check out: http://keyaccess.tucows.com/system/resource95.html

btw, Stel je voor dat je DirectX gebruikt, of iets anders in een eigen thread... je maakt 10x iets bepaalds voor dat object (Surfaces (bitmaps) ofzo), en je sluit je programma af.. zou het OS dan ook die surfaces weer un-allocaten? Waarschijnlijk niet. COM objecten (componenten) zijn volgens mij geheugen ramp #1...

[Verwijderd]

ik gebruik meestal een meegecompileerde unit die dat alles controleerd:

members.home.nl/gooijen/MemCheck.pas

uses memcheck;

en dan doe je om te loggen:

MemCheck.MemCheckLogFileName:='c:\log.txt';
MemCheck.MemChk;


voor info: zie file

[Verwijderd]

Op zaterdag 13 april 2002 15:47 schreef 41.6C.6D.61.72 het volgende:
Absoluut niet waar... er kunnnen nog bitmaps/Dc's in het geheugen blijven

Dat zijn een resource leaks, geen memory leaks

[Verwijderd]

@Deur
Bedankt, ik zal hem eens bekijken!

@Yarvieh
Semantics Ze zijn beide niet wenselijk.

[Sponge]

En denk je dat dat geen geheugen kost? De DC's zijn handles naar een bitmap [in het geheugen]

[Verwijderd]

Mijn definitie van een memory leak is dat de *code* geheugen is vergeten vrij te geven waar het geen referenties meer naar heeft.

[Verwijderd]

Op zaterdag 13 april 2002 15:47 schreef 41.6C.6D.61.72 het volgende:

[..]

Absoluut niet waar... er kunnnen nog bitmaps/Dc's in het geheugen blijven, hooks/subclassing kunnen dingen behoorlijk verzieken.

die dingen die jij opnoemt worden allemaal automatisch vrijgegeven, hooks,DC's, en alle andere kernel-objects. en alle user-objects worden getrashed omdat de volledige adress-space wordt vrijgegeven/vernietigd

[Sponge]

Dat wel, maar meestal blijft er nog een zooi achter.. zeg maar een uninstaller.. de helft van je zelfgemaakte stuff blijt op je HD staan =o)

[Verwijderd]

als je daar bijvoorbeeld tijdelijk aangemaakte bestanden bedoeld, dan heb je gelijk, maar daar ging het niet concreet over.

[Verwijderd]

Op zaterdag 13 april 2002 15:56 schreef deur het volgende:

[..]

die dingen die jij opnoemt worden allemaal automatisch vrijgegeven, hooks,DC's, en alle andere kernel-objects. en alle user-objects worden getrashed omdat de volledige adress-space wordt vrijgegeven/vernietigd

Ah, dus er kunnen helemaal geen resource- of memory leaks ontstaan (onder Windows)?

[Verwijderd]

als je een goede structuur aanhoud, vergeet je nooit om objecten/geheugen vrij te geven:

code:

var a:pointer;
begin
a:=nil;
try
  getmem(a,1000);
  .
  .
  .
finally
  freemem(a);
end;

.
.
.


var a:TObject;
begin
a:=nil
try
  a:=TObject.create;
  .
  .
  .
finally
  a.free;
end;

[Verwijderd]

Op zaterdag 13 april 2002 16:02 schreef Aegis het volgende:

[..]

Ah, dus er kunnen helemaal geen resource- of memory leaks ontstaan (onder Windows)?

niet als je programma afgesloten is. terwijl je programma runt, kan dat natuurlijk wel.

[Verwijderd]

Op zaterdag 13 april 2002 16:10 schreef deur het volgende:

[..]

niet als je programma afgesloten is. terwijl je programma runt, kan dat natuurlijk wel.

Ooooh, nou dan voorzie ik geen problemen. 't Is inderdaad niet zo dat ik in een superloop objecten zit aan te maken ofzo... . Bedankt.

[Sponge]

Op zaterdag 13 april 2002 16:10 schreef deur het volgende:

[..]

niet als je programma afgesloten is. terwijl je programma runt, kan dat natuurlijk wel.

En dat geheugen komt weer terug als ik het programma afsluit? Volgens mij gebeurt dat niet, anders zou niemand zich zorgen maken over geheugen lekken, terwijl ze toch nog zo vaak voorkomen

[Verwijderd]

Op zaterdag 13 april 2002 16:24 schreef 41.6C.6D.61.72 het volgende:
En dat geheugen komt weer terug als ik het programma afsluit? Volgens mij gebeurt dat niet, anders zou niemand zich zorgen maken over geheugen lekken, terwijl ze toch nog zo vaak voorkomen

Als je applicatie maar enkele minuten loopt, zou dat kloppen idd, maar als je app enkele uren/dagen loopt en enkele kb's per seconde lekt zou ik me toch wel zorgen gaan maken over memory leaks...

[Verwijderd]

Zoek op deze Torry page 's naar MemCheck v.2.54

Ideaal klein dingetje om je Delphi memory leaks mee te tackelen!

[Orphix]

Op zaterdag 13 april 2002 16:02 schreef Aegis het volgende:

[..]

Ah, dus er kunnen helemaal geen resource- of memory leaks ontstaan (onder Windows)?

Jawel, als je bv met COM objecten gaat werken moet je bij gebruik referenties toevoegen en wanneer je klaat bent die referentie weg halen. Als niemand meer naar dat COM object verwijst wordt het vrijgegeven (Garbage collection dus). Een COM object leeft in z'n eigen proces, als jouw programma een referentie naar een com object NIET weghaalt bij het afsluiten zal het COM object niet worden vrijgegeven, waarschijnlijk nooit meer tot het afsluiten van je OS.

[Sponge]

Precies! Alleen ik kon het niet zo goed verwoorden vanmiddag

[Verwijderd]

Op zaterdag 13 april 2002 18:10 schreef Orphix het volgende:
Een COM object leeft in z'n eigen proces, als jouw programma een referentie naar een com object NIET weghaalt bij het afsluiten zal het COM object niet worden vrijgegeven.

Dit geld uiteraard alleen voor Com objecten die out of process draaien (in 'n Surrogate process dus meestal dllhost maar je mag ook je eigen custom Surrogate schrijven) meer dan 99% van alle com objecten draaien in process (dus gewoon in de memory space van je process) en worden ook gewoon opgeruimt bij het sluiten van je process zelfs als wat 'n refcounting bugjes hebt.

[Verwijderd]

ik (in c++ althans) gebruik altijd de win32 api functies
GlobalAlloc & GlobalFree.
Maar ik bouw er een eigen funtie omheen die ik binnen mijn source aanroep. (die noem ik dan mem_alloc & mem_free). En dan heb ik twee globale variabelen alloc_count & free_count.
Bij een mem_alloc aanroep: alloc_count++
Bij een mem_free aanroep: alloc_free++

En dan doe je: alloc_count - free_count en je weet precies hoeveel items er in je geheugen staan die nog vrijgegeven moeten worden.
Je kan ook nog een systeempje verzinnen voor de size (dus niet de count) maar dat is wat lastiger. Omdat je met mem_free de size niet weet. Maar daar zijn truukjes voor te verzinnen....

[Ericston]

Op zaterdag 13 april 2002 15:34 schreef 41.6C.6D.61.72 het volgende:
rogramma toch nog in het geheugen, als je bijv Unreal Tournament ziet..eerste keer opstarten kost een halve minuut..2de keer ongeveer 5 seconden...

Dat wordt gecached geloof ik.

[curry684]

Op zaterdag 13 april 2002 15:46 schreef Yarvieh het volgende:
Bij het afsluiten van een process wordt al het gealloceerde geheugen door het operating systeem vrij gegeven.

Wat dan ook meteen aangeeft wat het echte gevaar is van een memory leak: dat je een programma schrijft dat uren/dagen/weken blijft draaien (services, IDE's, Officepakketten) en per uur al of niet actief gebruik een hoger geheugengebruik noteert.

Borland C++ Builder is een goed voorbeeld van een wandelende memoryleak: na opstarten ong. 50-60Mb in gebruik en zodra je een paar keer gecompileerd hebt op grote projecten kruipt ie al snel richting 200-300Mb. Afsluiten en herstarten geeft je dan spannende grafiekjes in Task Manager (350Mb in use --> 100Mb --> 150Mb )

Maarruh daar je Delphi 6 hebt: zoek eens snel in je helpfiles naar CodeGuard, dat doet precies wat je vraagt.

[curry684]

Addendum:

Als je een OCX schrijft die binnen bijvoorbeeld Internet Explorer gebruikt wordt ben je *heel* hard verplicht geen mem-leaks te maken, want dat ding draait in de address space van IE en als je bij het afsluiten nog geheugen over hebt is *zijn* memory-administration dus verneukt, en dan blaas je IE heel hard op

(ervaring ja)

[MisterE]

wat jij nodig hebt is MemProof.
Dit is speciaal gemaakt of leaks op te sporen in delphi.
je kan zien wanneer mem gereserveerd is en wanneer vrijgegven word.

eem 'memory monitor' heb je niet zoveel aan.....

http://www.automatedqa.com/products/memproof.asp