[DUG] Memcheck (an overview of features)

[Sean Cross - CRM]

I should have been more specific.  Memcheck makes it easier to locate leaks.  While FastMM reports more leaks, it is not much help in finding them (unless I am missing something).

Regards

Sean
-----------------------------
Sean Cross
Systems Development

CRM
PO Box 230
Napier
Phone:   06 835 5868
Mobile:  021 270 3466
Email:   sean.cross at crm.co.nz


 

> -----Original Message-----
> From: delphi-bounces at ns3.123.co.nz 
> [mailto:delphi-bounces at ns3.123.co.nz] On Behalf Of Ben Taylor
> Sent: Thursday, 1 December 2005 1:59 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: RE: [DUG] Memcheck (an overview of features)
> 
> > FAstMM should be used for production work.  Memcheck is better at 
> > detecting leaks though so it is better when debugging.
> 
> I'd have to disagree there. fastmm has much better leak reporting. 
> 
> however, memcheck currently makes it much easier to locate a 
> leak, due to it's 'integration' with the ide (when it raises 
> exceptions on the lines causing the leaks).
> 
> examples:
> 
> 1)
> 
>   TmyRec = record
>     myStr:string;
>   end;
>   PmyRec=^TmyRec;
> 
> var
>  p:PmyRec;
> begin
>  p:=AllocMem(SizeOf(TmyRec));
>  p.myStr:='sometext';
>  FreeMem(p);
> 
> memcheck will report no leaks. fastmm will correctly report a 
> leaked string. adding  p.myStr:=''; is required before 
> freeing the record.
> 
> 2) memcheck will also miss objects that are created in 
> initialization sections. eg:
> 
> initialization
> 
>   TObject.Create;
> 
> fastmm also provides detection of many 'bad memory use' 
> situations, including the following common ones:
> 
> 1) buffer overruns. (fastmm can't be perfect in this area, it 
> will miss some.)
> 
> var
>  s:string;
> begin
>  SetLength(s,10);
>  s[15]:='x';
> 
> 2) fastmm can detect you're calling a virtual method on an 
> already-freed object. it tells you the object that used to be 
> there, and what method you called (in this case, TWinControl 
> and Destroy);
> 
> var
>  o:TComponent;
> begin
>  o:=TWinControl.Create(nil);
>  o.Free;
>  //<snip> some other code in your app
>  o.Free;
> 
> 3) memory modified after being freed:
> 
> var
>  p:PChar;
> begin
>  p:=AllocMem(10);
>  FreeMem(p);
>  p[5]:=#50;
>  p:=AllocMem(10); //will raise exception here  FreeMem(p);
> 
> good coding practices can prevent these situations happening 
> in the first place, but
> 1) everyone makes mistakes, and 2) there's a good chance 
> you're using other people's code.
> 
> fastmm is also designed to resist memory fragmentation, is 
> more consistent in the time taken to allocate memory, and is 
> generally significantly faster than the standard borland mm. 
> this is most useful for long running or memory allocation 
> intensive applications, eg applications running as a service. 
> depending on the application, you could expect a 20% increase 
> in speed "for free".
> 
> fastmm is in dexter/delphi2006, but i'm half expecting all 
> the useful debug code will be removed (and i agree with 
> that). you will still be able to replace it with the 'full' 
> fastmm (or even the old borland mm). due to fastmm's 
> different handling of memory, it is likely to expose existing 
> (undiscovered) bugs in people's applications. if you want to 
> prepare for d2006, it would be a good idea to try fastmm now, 
> and make sure your app is behaving as it should be :-)
> 
> anyway, hope someone finds this "+1, interesting" ;-)
> 
> b
> 
> Send instant messages to your online friends 
> http://au.messenger.yahoo.com 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
> 
>