Why optimization crashed the application I was working on...

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.


  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.

Published Tue, 12 Nov 2013 @ 11:45 AM by chuacw
Related articles: ,

Comments (Will be reviewed before being published)

# re: Why optimization crashed the application I was working on...

Tuesday, November 12, 2013 1:09 PM by Moz

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).

Leave a Comment

Enter the following code to ensure that your comment reaches the intended party:
Enter the numbers you see in the image: