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.
290 stars 75 forks source link

Invalid Pointer #18

Open wesleybobato opened 4 years ago

wesleybobato commented 4 years ago

Hi Pierre

I am getting an invalid pointer operation error, I am attaching some images to show the exact location in FastMM5.pas

I'm using Delphi Tokyo 10.2 Update 3 My Project is 32 Bits

Any tips to get around the problem do not use any configuration specifies just add FastMM5 as first in the list of Uses in the DPR file

Thanks.

001 002 003

pleriche commented 4 years ago

Hi Wesley,

What you're seeing is most likely the effect of an earlier memory pool corruption (most often a buffer overrun). Please try enabling debug mode (call FastMM_EnterDebugMode on startup) and see if that perhaps sheds more light on what is going wrong. It may also be helpful to call FastMM_ScanDebugBlocksForCorruption at regular intervals in order to narrow down when the corruption is happening.

Pierre

wesleybobato commented 4 years ago

Hello Pierre Again

When I called FastMM_EnterDebugMode at program startup I get error messages, even calling FastMM_ScanDebugBlocksForCorruption the error occurs and closes the program.

I am attaching some images and a log.

Thanks.

001 002

MemoryManager_EventLog.txt MemoryManager_EventLog2.txt

pleriche commented 4 years ago

Ok, so what is likely happening here is that the application is still attempting to use blocks (perhaps objects) after it has freed them. It could also just be due to a bad pointer dereference, but the former is the more likely culprit.

Next you need to enable stack traces so you can see exactly where the block was allocated and where it was freed: 1) Ensure that the FastMM_FullDebugMode.dll library is in the same folder as the application executable, (There is a precompiled copy in the "FullDebugMode DLL\Precompiled" subfolder.) 2) Ensure that the debug support library has all the info it needs to be able to convert stack trace addresses to unit and line number information. The easiest way to do that is to provide it with a map file: Project Options -> Delphi Compiler -> Linking -> Map File -> Detailed.

With both the debug support DLL and the map file accessible the crash dumps above should contain detailed stack traces showing where the block was allocated and where it was freed. Normally this is all the information needed to pinpoint and consequently fix the issue.