Board index » delphi » FastMM debug help

FastMM debug help


2006-04-11 12:58:15 AM
delphi280
Hello!
To help me debug an invalid pointer error, I have installed FastMM and am now
building my code with it. Using this library, when performing an operation,
I get an error about an object being modified after it has been freed.
Looking at the memory dump, I can see the following:
Current memory dump of 256 bytes starting at pointer address 82109F8:
48 57 Delphi 8 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 00 00 00 00 80
80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
There are four bytes that are set to zero in there and I was wondering what
I need to understand and what I need to do in order to convert that offset
to an actual property of the object.
Can anyone give me some pointers (no pun intended) as to how to do this? Is
there an application that can do this calculation for me?
Thanks!
Regards,
Steffan
 
 

Re:FastMM debug help

Hi Steffan,
Quote
Can anyone give me some pointers (no pun intended) as to how to do this?
Is
there an application that can do this calculation for me?
Unfortunately there's no tool to do that, but it is certainly a good idea.
Perhaps something I should look at in a future version of FastMM.
To find the property that is being written you need to go to the base class
descending off TObject and start adding up the sizes of fields until you get
the field matching that offset. It can be a bit tricky, since you have to
take into consideration alignment (default is $A8) and also the leading 4
bytes which is always the class pointer. You're looking for the field
starting at offset 52 if I counted correctly.
If you can not manage you're welcome to post you class declaration here and
I'll decipher it for you.
Regards,
Pierre
 

Re:FastMM debug help

Hi Pierre!
Thanks for your offer. I found another way to get the information I
needed. Just in case someone else needs the info, here's how to
interpret the data. Pierre, please correct me if this is incorrect. It
worked for me.
When you get an error dialog from FastMM about an object being modified
after being freed, you get some stack traces and a memory dump. The
memory dump is 256 bytes but FastMM tells you how much memory was used
by the object. So only take the number of bytes that FastMM tells you
was used by the object. In my case, the object used 144 bytes. So the
useful info is below:
Current memory dump of 256 bytes starting at pointer address 82109F8:
48 57 Delphi 8 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 00 00 00 00 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
FastMM fills the memory with 80 when the object is freed and the first
four bytes are the pointer to the VMT. In my case above, at byte 84,
there are four straight 00 bytes. This is what was changed after
freeing the object.
In order to identify what was modified, I did the following... I ran my
application in debug mode and put a breakpoint somewhere in the class.
When the breakpoint was hit, I brought up the evaluation debug window
and entered the following: Integer(@self.<FMyBuffer>) - Integer(Self)
<FMyBuffer>points to the first the private variables in the class. If
the value is less than the byte you are looking for, take the first
private variable of the ancestor class and try again. Then do a binary
search throught the class until you find the private variable that is at
the memory offset you are looking for.
Worked for me in two different situations. Hopefully will work for
anyone else too.
Pierre, thanks a lot for this tool!! Amazing! Helped me debug a client
problem that was impossible for me to reproduce.
Regards,
Steffan
Pierre le Riche writes:
Quote
Hi Steffan,

>Can anyone give me some pointers (no pun intended) as to how to do this?
>Is
>there an application that can do this calculation for me?

Unfortunately there's no tool to do that, but it is certainly a good idea.
Perhaps something I should look at in a future version of FastMM.

To find the property that is being written you need to go to the base class
descending off TObject and start adding up the sizes of fields until you get
the field matching that offset. It can be a bit tricky, since you have to
take into consideration alignment (default is $A8) and also the leading 4
bytes which is always the class pointer. You're looking for the field
starting at offset 52 if I counted correctly.

If you can not manage you're welcome to post you class declaration here and
I'll decipher it for you.

Regards,
Pierre


 

Re:FastMM debug help

Hi Steffan,
Quote
Thanks for your offer. I found another way to get the information I
needed. Just in case someone else needs the info, here's how to interpret
the data. Pierre, please correct me if this is incorrect. It
Thanks for the feedback. I use a similar process to find the modified field:
I usually use the InstanceSize call of the ancestor class(es) to determine
in which class to start looking. Once I know in which ancestor class the
field lies, I just add up its field sizes until I find the culprit.
Regards,
Pierre