About the author
I was working on an application, that uses an external library, a DLL. After finishing on the debug version, I decided to try the release version, and run my unit tests on it. Immediately, I started to notice that all my unit tests failed. I began to tinker with the options available, and soon discovered that switching on "Optimization" creates a very difficult to trace bug, which only happens occasionally.
var Instance: TSomeObject;
In my code, I had something looking like the above declaration.
If you look at the above assembly code, you'll noticed that the EBX register's value is being moved back to EAX. Then, after tracing around, it seemed that the external routine (call dword ptr [eax+$78]) in the DLL I was calling was trashing the Instance variable, which was stored in EBX. According to Program Control on the Embarcadero Docwiki, all functions and procedures are supposed to preserve EBX (among others). Since the external library can't be changed, switching off optimization in the units where the routine is used, via the compiler directive {$OPTIMIZATION OFF}, removes the error, because the Instance variable is no longer stored in EBX. And for the rest of the project, optimization is set to on via Project Options.
You might be amused to find that there's a tool for victims of C/C++ that specifically looks for errors caused by compiler optimisation: css.csail.mit.edu/stack
I'm not sure that it would find that particular error, it mostly targets undefined but legal behaviour, which isn't an issue for Delphi since it doesn't follow a standard (hence, no undefined).
How to free more space on your home drive by redirecting the location for SDKs in RAD Studio
Learn the command line used to compile System.pas in Delphi
A method to design records so that they're allocated on a specific byte boundary, such as 16 bytes, 512 bytes, 4096 bytes, etc.
Learn why the map is cool in Go!