-1

I'm using Delphi 10.1 and Windows 10, with all current updates.

My application uses and re-uses a large number of dynamic arrays, 50 or more, each having up to 5,000 elements. During execution, these arrays are cleared using either SetLength(thearray,0) or thearray:=nil. Immediately following this, a new size is assigned with SetLength(thearry,newsize).

For most of the arrays, this works smoothly. But occasionally, one or another of these allocations (the same one every time the program runs) crashes without an exception or other notice. The crash can occur on either the clear function or on the sizing function. The program has to be closed using Program Manager and then restarted.

The really odd thing is that the array causing the crash can change depending on the memory manager employed -- native Delphi, ScaleMM2, FastMM4. In the past, I've sometimes solved the problem by renaming arrays, but the problem pops back up from time to time after multiple changes and recompiles.

The machine's RAM checks out fine, and the problem persists on multiple machines.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
mfiring
  • 1
  • 2

1 Answers1

8

This is because of a defect in your code, heap corruption, double free, buffer overrun, etc. The unpredictability of the error is consistent with such an error.

Don't look for the error elsewhere. It won't be the memory manager. It won't be the hardware. It won't be the names of your variables. It's your code that is at fault.

Start debugging this by dialing up the diagnostics tools. Enable range checking in the compiler options. Switch to the full debug version of FastMM4. Hopefully these changes will be enough to isolate the fault. If not, cut the code down until you have a minimal reproduction. That way you will have less code to inspect.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Thank you Mr. Helferman. The problem is not random. The program iterates through some 8,000 cycles each executing the same code. Using ScaleMM2 the error occurs on cycle 343. Using FastMM4 the error occurs on cycle 1,825. All of the other cycles execute the same code without problems. I've enabled Range Checking, but that doesn't generate an exception. Your suggestion regarding double free is intriguing and I'll try to find something like that, but given the many successfully executed cycles it's odd that it wouldn't protest earlier. – mfiring Aug 21 '18 at 15:24
  • Additionally, why does the IDE crash and become non-responsive? – mfiring Aug 21 '18 at 15:28
  • Not really odd. Not at all surprising. Keep debugging. – David Heffernan Aug 21 '18 at 16:26