|
| Visual C++ mem leaks Fra : Rasmus Christensen |
Dato : 03-05-01 14:55 |
|
Hejsa
Jeg har et lille problem med at finde tilbage til mine memory leaks i en
MFC-applikation, der bruger extension dll'er.
Problemet er, at objekter allokeret i disse dll'er godt nok rapporteres som
memory leaks, men konsollen viser kun sådan noget som:
[...]
Dumping objects ->
#File Error#(663) : {166780} client block at 0x028E8B70, subtype 0, 188
bytes long.
an invalid object at $028E8B70, 188 bytes long
#File Error#(663) : {166779} client block at 0x028E8C60, subtype 0, 188
bytes long.
an invalid object at $028E8C60, 188 bytes long
[...]
Nogen, der har forslag til, hvordan man igen får sine filnavne og linjnumre
for allokeringen ind igen? Jeg ved, at problemet opstår, fordi dll'erne,
hvor allokeringen skete allerede er unloaded inden applikationen dumper, og
har derfor også prøvet selv at indsætte memory checkpoints. Det giver dog
bare en masse garbage, dvs. falske mem leaks for objekter, som bliver
slettet, når dll'en unloades.
På forhånd tak
Rasmus Christensen
| |
Mogens Hansen (03-05-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 03-05-01 16:52 |
|
Hej Rasmus,
"Rasmus Christensen" <riverwind@mail.tele.dk> wrote in message
news:JqdI6.109$cQ1.39740@news.get2net.dk...
> Hejsa
>
> Nogen, der har forslag til, hvordan man igen får sine filnavne og
linjnumre
> for allokeringen ind igen? Jeg ved, at problemet opstår, fordi dll'erne,
> hvor allokeringen skete allerede er unloaded inden applikationen dumper,
og
> har derfor også prøvet selv at indsætte memory checkpoints. Det giver dog
> bare en masse garbage, dvs. falske mem leaks for objekter, som bliver
> slettet, når dll'en unloades.
Brug NuMega BoundsChecker eller Rational Purify.
Venlig hilsen
Mogens Hansen
| |
Rasmus Christensen (03-05-2001)
| Kommentar Fra : Rasmus Christensen |
Dato : 03-05-01 17:06 |
|
Mogens Hansen <mogens_h@dk-online.dk> wrote in message
news:9cruph$dm7$1@news.cybercity.dk...
[...]
> Brug NuMega BoundsChecker eller Rational Purify.
[...]
Jo tak, jeg har også prøvet Purify. Det irriterende ved den er bare, at den
er *meget* ressourcekrævende. Og eftersom applikationen, som jeg skal
debugge også er temmelig tung, så ender det som regel bare i, at Purify
crasher.
BoundsChecker har jeg ikke prøvet, men det kunne være, at det kunne betale
sig.
Mvh
Rasmus
| |
Mogens Hansen (03-05-2001)
| Kommentar Fra : Mogens Hansen |
Dato : 03-05-01 17:14 |
|
Hej Rasmus,
"Rasmus Christensen" <riverwind@mail.tele.dk> wrote in message
news:FlfI6.244$cQ1.47775@news.get2net.dk...
> Mogens Hansen <mogens_h@dk-online.dk> wrote in message
> news:9cruph$dm7$1@news.cybercity.dk...
> [...]
> > Brug NuMega BoundsChecker eller Rational Purify.
> [...]
>
> Jo tak, jeg har også prøvet Purify. Det irriterende ved den er bare, at
den
> er *meget* ressourcekrævende. Og eftersom applikationen, som jeg skal
> debugge også er temmelig tung, så ender det som regel bare i, at Purify
> crasher.
Ja, det har jeg også set.
> BoundsChecker har jeg ikke prøvet, men det kunne være, at det kunne betale
> sig.
Den er udemærket når den instrumenterer koden.
Jeg har dog oplevet både Purify og BoundsChecker give "falsk positiv" og
"falsk negativ" resultater.
Selv bruger jeg mest CodeGuard, som er en del af Borland C++Builder V5.0
Professional og Enterprise. Den har jeg _meget_ gode erfaringer med - men
det hjælper nok ikke dig.
Jeg kan ikke huske at den har meldt fejl, hvor der ikke var noget om
snakken.
Jeg kan ikke huske at andre værktøjer har fundet fejl som CodeGuard ikke har
fundet - og jeg har prøvet en del.
CodeGuard vil kunne finde problemer i de flestes kode af og til!
Venlig hilsen
Mogens Hansen
| |
michael Nielsen (07-05-2001)
| Kommentar Fra : michael Nielsen |
Dato : 07-05-01 17:00 |
|
Du kan også forsøge dig med MFC egne debug rutiner, I dit eksempel vil
et kald til _CrtSetBreakAlloc() kunne fortælle dig hvilket
objekt der ikke bliver nedlagt.
CrtSetBreakAlloc tager allokerings nummeret som argument, f.eks
CrtSetBreakAlloc(166779) for nedenstående dump.
#File Error#(663) : {166779} client block at 0x028E8C60, subtype 0, 188
Må dit hus fyldes med børn og din stald med kameler.
Mvh.
Michael Nielsen
"Rasmus Christensen" <riverwind@mail.tele.dk> wrote in message
news:JqdI6.109$cQ1.39740@news.get2net.dk...
> Hejsa
>
> Jeg har et lille problem med at finde tilbage til mine memory leaks i en
> MFC-applikation, der bruger extension dll'er.
> Problemet er, at objekter allokeret i disse dll'er godt nok rapporteres
som
> memory leaks, men konsollen viser kun sådan noget som:
> [...]
> Dumping objects ->
> #File Error#(663) : {166780} client block at 0x028E8B70, subtype 0, 188
> bytes long.
> an invalid object at $028E8B70, 188 bytes long
> #File Error#(663) : {166779} client block at 0x028E8C60, subtype 0, 188
> bytes long.
> an invalid object at $028E8C60, 188 bytes long
> [...]
>
> Nogen, der har forslag til, hvordan man igen får sine filnavne og
linjnumre
> for allokeringen ind igen? Jeg ved, at problemet opstår, fordi dll'erne,
> hvor allokeringen skete allerede er unloaded inden applikationen dumper,
og
> har derfor også prøvet selv at indsætte memory checkpoints. Det giver dog
> bare en masse garbage, dvs. falske mem leaks for objekter, som bliver
> slettet, når dll'en unloades.
>
> På forhånd tak
> Rasmus Christensen
>
>
| |
|
|