search

pleriche / FastMM5

FastMM is a fast replacement memory manager for Embarcadero Delphi applications that scales well across multiple threads and CPU cores, is not prone to memory fragmentation, and supports shared memory without the use of external .DLL files.
278 stars 73 forks source link

nil in LPShortString in BlockContentTypeToTextBuffer #51

Open Nashev opened 3 months ago

Nashev commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

Nashev commented 3 months ago

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.