nil in LPShortString in BlockContentTypeToTextBuffer

[Nashev]

I have tried to use FastMM_LogStateToFile which have a nested calls of BlockContentTypeToTextBuffer procedure in my code for explore some memory leaks, and have faced with situation, when in LPShortString after line

LPShortString := PShortString(PPointer(PByte(LClass) + vmtClassName)^); 

was nil and further manipulation with it fails and prevent to write a memory usage dump.

I do not remember now, what the object leads to this misbehaviour, but when I added a code like

      if LPShortString = nil then
        Result := AppendTextToBuffer('<nil class name>', Length('<nil class name>'), Result, APTargetBufferEnd)
      else
        begin

it wrote one line about this nil, and all others data was very useful for my purposes.

[pleriche]

Is it possible that the block content was modified after it was detected as a class? (Perhaps by another thread?) Unfortunately it's risky to try and log the content of a memory block while other threads may be manipulating those same blocks.

I could add that nil check, but there would still be a race condition - another thread could very well free the entire block immediately after the nil check, which would still lead to a crash.

[Nashev]

May be, but size and count of that memory blocks was stable across the long time.

[Nashev]

Anyway, I expect FastMM_LogStateToFile to work in enough independently, relative to other memory management routines. I would like to think this nil is from some RTTI-storing issue, not from race conditions.

[pleriche]

I have recently added some additional sanity checks to FastMM_DetectClassInstance that I believe may solve this issue as well.

[Ilia-Nenashev-devX]

Just for info, You have mean the 58d018c commit.

Also may be the next d8b4905 is a little bit related.

I'm not sure this fixes my issue, but yes, it may be.