pleriche
nil in LPShortString in BlockContentTypeToTextBuffer
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.
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.
May be, but size and count of that memory blocks was stable across the long time.
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.
I have recently added some additional sanity checks to FastMM_DetectClassInstance that I believe may solve this issue as well.
Just for info, You have mean the https://github.com/pleriche/FastMM5/commit/58d018c788f22d27a861cdb3b8a22c655357eb96 commit.
Also may be the next https://github.com/pleriche/FastMM5/commit/d8b49057b63350f6d654a9e317f589c2649d7ee9 is a little bit related.
I'm not sure this fixes my issue, but yes, it may be.
