"HEAP: Free Heap block 0A075450 modified at 0A0754B4 after it was freed"

General Help
1

Hi all,

Trying to track down what causes this Debug Output to be written HEAP: Free Heap block 0A075450 modified at 0A0754B4 after it was freed. I have search all the project’s sources, the VCL/RTL and haven’t found the text at all.

Tried to Google for it and didn’t find anything that I thought was relevant, so the last step is to ask the brains-trust here.

Any ideas on who is causing this message to be written out as a DebugOutputString? And when does it occur?

2

Fastmm will do that, but usually you have to have full debugging enabled.
(It might be in the fastmm_fulldebugmode.dll)

1 Like
3

I am uncertain where the message comes from, but calling methods in previously-freed objects is a really bad idea. The heap manager can reassign the memory block that the object occupied and this can result in random code execution when the method is called.

EurekaLog can be configured to throw an exception upon calling a method in a freed object in your application. This can vastly speed up revealing/debugging reuse-after-free bugs as your debugger will show exactly where the reuse occurred. EurekaLog will also create a crash report with a call stack showing where the reuse occurred. It can send the report back to your development team by a variety of methods.

Note that your app can successfully go for years calling methods in freed objects, but this can turn into a major crash. Changes to your app that cause the heap manager to reuse a critical memory block can result in a catastrophic failure.

There is a free trial version of EurekaLog available in GetIt or you can download it from our website.

Full disclosure: I work for Neos Eureka, the maker of EurekaLog.

1 Like
4

Thanks for the replies.

I definitely know accessing memory after it has been freed is a big no-no.
In this case, the application I was running/debugging was doing concurrent processing (a process which is known to be iffy™). But this is the first time that I have noticed these DebugOutputString in the IDE logs. If I had noticed it before, I would have definitely taken notice of the stack trace, now that I have searched for the message in a more generic way. I think it is Windows that is informing me about something that has gone wrong (quoted bits are from the website):

I’m calling malloc(6) and getting an error of the form:
HEAP[MyApp.exe]: HEAP: Free Heap block bf33b8 modified at bf3538 after
it was freed
This occurs during the malloc call, 5 or 6 calls deeper in
msvcr90d.dll and then ntdll.dll.

HEAP[Diokonika.exe]: HEAP: Free Heap block bb6970 modified at bb6a78 after it was freed
Windows has triggered a breakpoint in Diokonika.exe.

with a stack trace that runs from ntdll.dll to msvcp90d.dll to the app in question.

Message and similar stack trace to the one above

I have always thought that FastMM (v 4.991) kept hold of any memory that it might have asked for (but this could be a bad assumption on my part) but since it seems to be Windows telling me something is wrong, with memory allocation, which is outside what I have control of, I am not sure what I can do (except take note of the stack trace and try to figure out what/where/how it went wrong)…