/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
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
>
>



Søg
Reklame
Statistik
Spørgsmål : 177501
Tips : 31968
Nyheder : 719565
Indlæg : 6408522
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste