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.

Lieven Keersmaekers
  • 57,207
  • 13
  • 112
  • 146
rossmcm
  • 5,493
  • 10
  • 55
  • 118
  • 3
    perhaps FastMM is right? I know it has been for every time I thought *that can't be right?!* Can you post minimum code that reproduces the problem. – Lieven Keersmaekers Aug 26 '10 at 15:16
  • The application runs without flaw on normal Windows XP? – Fabricio Araujo Aug 26 '10 at 16:29
  • 2
    You say the problem is that your error-reporting tool is reporting an error, and your "cure" is to remove the reporting tool? That's known as "sweeping it under the rug." – Rob Kennedy Aug 26 '10 at 20:00
  • @Rob, but the problem *could* be in the reporting tool - a type of Heisenbug (http://www.catb.org/~esr/jargon/html/H/heisenbug.html)? – Gerry Coll Aug 26 '10 at 20:48
  • FWIW, I had an app that would break on the DPR **begin** if I used FastMM4. Never found out why. – Gerry Coll Aug 26 '10 at 20:50
  • The application runs fine under Windows XP on all PC's except this embedded XP tablet PC. A simple single form app without "uses fastMM4" runs fine on the tablet. A simple single form app with "uses fastMM4" crashes on startup with "The instruction at 0x00485562 referenced memory at 0x00a90878. The memory could not be read. Click on OK to terminate the program." Clicking on OK gives me a "Run-time error 216 at 00485562" snag box. Clicking on OK takes me back to the first message. The only way out is to kill the task. – rossmcm Aug 26 '10 at 21:30
  • Have you ever tried to look, what is this instruction on $00485562? Enable "Use Debug DUCs" and make full beuild to get source for that address. Run your app under debugger and use View/Goto address. – Alex Aug 27 '10 at 11:55
  • @Alexander. Thanks for your comments. I certainly intend to look closer at the simple app that fails. The other thing is that I have discovered - as I feared - that the full application compiled without "extra" FastMM crashes the whole PC eventually, so I may be looking at 2 problems here... – rossmcm Aug 27 '10 at 18:49
  • I'm perplexed. I compile the simple app with FastMM and debug DCU's, run it: "The instruction at 0x007333aa referenced memory at 0x00d409b8. The memory could not be read." I click on OK and get "The instruction at 0x007333aa referenced memory at 0x00d408d8. The memory could not be read.", i.e. same code address, different read address. I click on OK and get "Runtime error 216 at 007333AA". Delphi Search/Goto address "$007333AA" positions me at a mov ecx,[eax] with no sign of a label nearby. No address close to 007333AA or 003323AA (= 007333AA - 00401000) in the map file. Help! – rossmcm Aug 29 '10 at 22:14

2 Answers2

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.

himself
  • 4,806
  • 2
  • 27
  • 43
  • 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). – rossmcm Aug 26 '10 at 19:51
  • @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 Wiert Pluimers Aug 26 '10 at 22:05
  • @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 Aug 30 '10 at 12:50
  • It was a Delphi form app. I'll try a console app tomorrow. (you mean "Build with run-time packets", right?) Thanks, R. – rossmcm Aug 30 '10 at 17:02
  • 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? – rossmcm Aug 30 '10 at 20:25
  • 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 Aug 31 '10 at 12:27
  • 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. – rossmcm Aug 31 '10 at 14:28
  • 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... – rossmcm Aug 31 '10 at 21:06
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.

Alex
  • 5,477
  • 2
  • 36
  • 56