Why do I get memory errors from my Delphi 2006 app running under Windows XP embedded

Question

I have a D2006 app that uses FastMM4 (like, it has "FastMM4" in the start of the uses clause in the DPR file). I know Delphi uses FastMM4 as it's memory manager anyway, but the downloaded version has more debug dump options.

I recently tried to run the app on a single-board tablet type industrial PC running Windows XP embedded. The processor is a non-Intel "Vortex" chip. The app fails with a memory error on startup and then exits with a complaint from FastMM4 about accessing memory after it has been freed.

Removing all traces of FastMM4 from the source code seems to cure it - the app runs fine.

My question. What is it about the downloaded version of FastMM4 that causes this problem? I have seen anecdotal stuff about crashes with FastMM4 and non-Intel processors that seem to be related to the use of ASM code. FastMM4 includes a directive to force the generation of non-ASM code, but that doesn't cure the problem.

I'm a bit worried that problems might still exist with the integral D2006 version of FastMM4 and I just haven't seen it yet.

Answer 1

Rule #1: Blame your code first before blaming others.

Articles to find bug in your code: using memory manager in debug mode and memory problems in Delphi.

Answer 2

The answer is: nothing.

Windows XP Embedded is JUST Windows XP without some components, nothing more. Those components that are present are the same that in normal XP (binary equivalent, even). Basically XPE is XP with some of the DLLs deleted and some of the registry entries not present (I know I'm over-simplifying things here).

So, the only difference it makes to your app is that some of libraries might be missing and some of the components might not be properly installed. As far as I know FastMM does not rely on any special components apart from the core Win32 API which is very obviously present, or your app would not run at all (and hardly anything user-mode would).

Therefore the problem is not in FastMM4 but in something else. Most likely it's bad handling of missing libraries. Probably some part of your code dynamically loads DLL but fails to verify if it's really loaded, or reads some setting from registry and fails to handle missing data. This leads to memory corruption which, by the virtue of luck, becomes apparent when you use one memory manager, but does not with the other.