Tjena,

Jag håller på att reda ut lite minnesläckor i några av mina MFC applikationer:

I mitt debug fösnter får jag följande utskrivt
Detected memory leaks!
Dumping objects ->
C:\arbete\software\OutOfBox\Common\DosExec.cpp(19) : {1999} client block at 0x010A1E98, subtype 0, 164 bytes long.
a CDosExec object at $010A1E98, 164 bytes long
strcore.cpp(118) : {1998} normal block at 0x010A3BB0, 28 bytes long.
Data: < Plat> 01 00 00 00 0F 00 00 00 0F 00 00 00 50 6C 61 74

Raden som pekas ut har fölajnde innehåll:

IMPLEMENT_DYNCREATE(CDosExec, CWinThread)

Jag har sökt på nätet men inte hittat något. Överhuvud taget så får man väldigt ltie träffar på google
om man söker på "Detected memory leaks + IMPLEMENT_DYN_CREATE"
Saken är den att jag har flera klasser/andra applikationer som denna, och ifrån de får jag inga felmeddelanden.
Är detta en bugg i MFC?

Ett annat minnes fel jag får är rader dit jag allokerar minne dynamiskt med new och inte deallokerar det i samma funktion. Kan inte MFC fatta att man deallokerar senare i programet?
t ex:

void MyFunction(CPtrList *pList)
{
MyObject *p;
for ( int i = 0; i < 10; i++)
{
p = new MyObject;
pList->AddTail(p)
}
}

mvh

Pierre

Vad gäller den andra funktionen: Det är extremt svårt för en kompilator att förstå såna saker, därav meddelanden. Nakna pekare är inget man egentligen ska använda; man bör köra med smarta pekare, tyvärr råkar inte Microsoft ha förstått det när de designade MFC. (Och de hade väl inte direkt förstått OO heller...) Hade man haft smarta pekare istället hade det varit enklare att förstå beteendet, men framförallt så hade det varit "omöjligt" att skapa minnesläckor.

Vad gäller det första meddelandet: Känner inte till problemet. Men en viktig punkt är detta:
1. Hur används programmet?
2. Är det "modernt", eller kommer det skrivas om snart?

Om programmet bara används vid enstaka tillfällen, och inte under längre perioder, så spelar faktiskt inte minnesläckor så stor roll. Och om programmet kommer skrivas om av en eller annan anledning, så är det nog inte värt slitet att försöka leta reda på felen.

1) Programmet används i produktionslinan som testverktyg och har fungerat bra än så länge.
Med andra ord så går programmet 24h om dygnet.

2) Programmet gjorde jag i sommras och gör successivt uppdatering när produktionen ändras.

Anledningen att jag vill fixa det är att det känns och ser bättre ut om man inte får några fel när man stänger ner programmer i utvecklingsmiljön, även om det funger problemfritt under användning.
Och så hade jag lite tid över nu innan Jul :-)

// Pierre

1) Programmet används i produktionslinan som testverktyg och har fungerat bra än så länge.
Med andra ord så går programmet 24h om dygnet.

Har minnesanvändningen någon gång ökat för att aldrig gå ner igen?
Har den inte det så kan det ju vara så enkelt att du har en minnespool istället, och då är det absolut inget att oroa sig för. Det innebär bara att en viss, begränsad minnesarea aldrig lämnas tillbaka. Eftersom operativsystemet ändå tar tillbaka allt minne när programmet avslutas så spelar det ingen som helst roll.

2) Så det finns alltså folk som fortfarande använder MFC... =)
Mitt bästa råd är att istället använda ett lite trevligare framework (t.ex. QT) i kombination med standardbiblioteket (det som förut kallades för STL).

1)Angående minnesanvändning så fösvinner inget.

2) Jag var lika förvånad själv att de använder MFC när jag påbörjade detta uppdrag.
Jag har ifrågat satt dem varför de inte använder t ex C# för att göra GUI och det svar jag har fått är
att någon har "dålig erfarenhet" av det. Eftersom jag är konsult så förde jag inte diskussionen vidare utan hoppas på nytt uppdrag :-)

Då är "minnesproblemet" inte en riktig minnesläcka. Du kan ignorera hela grejen, såvida inte minnesanvändningen någon gång börjar gå upp. Förmodligen är det så att det är en minnespool, och det är helt ofarligt; men samtidigt är det grymt svårt för en kompilator att förstå hur den fungerar och att den faktiskt inte kan allokera hur mycket minne som helst. Kolla om det finns någon debugger som kan hålla reda på hur mycket minne som inte är avallokerat vid avslut. Förmodligen är det lika mycket varje gång, oavsett hur länge du kör.

Ang. språk:
Jag hade ju hellre använt C++ med bra bibliotek än C#, men det är ju en smakfråga. =)

>Ett annat minnes fel jag får är rader dit jag allokerar minne dynamiskt med new och inte deallokerar det
>i samma funktion. Kan inte MFC fatta att man deallokerar senare i programet?
>t ex:

Kompilatorn lägger in kod som markerar alla minnesallokeringar. Vid delete så prickas de av oavsett om det görs i samma funktion eller inte. När du avslutar programmet så kollas om alla minnesallokeringar är avprickade. De som inte är avprickade listas så de som listat är verkliga minnesläckor.

Det jag har sett är däremot att kontrollen ibland sker före alla destructors för statiska objekt har körts.

Har inte använt IMPLMENT_DYNCREATE men har för mig att hela idén är att minnet sköts av MFC.

Min gissning är att problemet är dina andra minnesluckor och att IMPLMENT_DYNCREATE bara visas eftersom MFC destruktors inte har körts ännu.

<b>>De som inte är avprickade listas så de som listat är verkliga minnesläckor.</b>
Förutom minnespooler förstås.

Definitionen på en minnesläcka är något i stil med att ett program allokerar minne, och någon gång under körningen blir av med en pekare till minnet. "Jag har allokerat, men jag vet inte var de är". Det kan leda till vilket sorts beteende som helst; framförallt så kan minnesanvändningen växa obegränsat.

Definitionen på en minnespool är snarare att ett program allokerar minne och sen hela tiden håller minnet. De vanligaste implementationerna struntar i att lämna tillbaks minnet eftersom de används under en hel applikations livstid. Det är alltså fullt möjligt att allokera minne och inte avallokera det, och ändå inte ha en minnesläcka.

Givetvis så var det ju "skit bakom spakarna" i ett av fallen :-)
Jag hade missat att avallokera minne på ett ställe.

Dock så återstår IMPLEMENT_DYNCREATE() felet.

Hehe... allt prat om minnespooler i onödan. Men det <b>hade</b> kunnat vara så.

Ang. Dyncreate: http://www.codeguru.com/forum/archive/index.php/t-89940.html verkar ha en diskussion som gränsar till det.