views:

130

answers:

2

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.

+1  A: 

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.

himself
One of the first things I did when I had this issue was to verify that a "hello world" app also exhibited the problem (it does).
@user89691: probably your Windows XP Embedded lacks so many things (I know: I have built XP Embedded images that not even have can run a GUI) that makes your Delphi app fail. It is just that the FastMM portion mentions that it failes.
Jeroen Pluimers
@user89691: Was that console hello world or delphi forms hello world? Try a console one, less dependencies. Make sure "build with packets" is disabled. Still fails?
himself
It was a Delphi form app. I'll try a console app tomorrow. (you mean "Build with run-time packets", right?) Thanks, R.
OK: "Build with run-time packets" is off. Optimization off. Range, overflow, I/O checks on. Use debug DCUs on. Hello world console app without "uses fastmm" runs fine. Console app with "uses fastMM" gives exactly the same behaviour as the simple form app except address is "The instruction at 0x004233aa referenced memory at 0x00a309b8", i.e. both addresses are less by 0x00310000. Any ideas?
Did you enable FullDebugMode? It requires FastMM_FullDebugMode.dll to be present. Try this HelloWorld: http://www.mediafire.com/?pug96vij07n7c9c (sources+exe inside). Does it fail on your embedded system?
himself
Arrgghh. You may be right. FullDebugMode is enabled and I'm not sure if the DLL was installed. Its 2am and it will be 5hrs until I can try it. It's caught me before, this one, but usually the error message is a bit more helpful. Now, interestingly, the full app (but not the hello world app) fails eventually with a floating point overflow. Your help on this is much appreciated. Watch this space.
5 hours later.... FastMM_FullDebugMode.dll is present in System32. Your HW app runs fine! I recompiled my HW app with FullDebugMode off and voila - it also runs. Now trying to get the big app running...
+1  A: 

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.

Alexander