Delphi: EInvalidOp exception, might just mean you have a use-after free scenario, or an out-of-bounds value

Quite sometime I was researching spurious exceptions in a Delphi application, then finally replicated them in a unit test suite.

One of them was occurring almost all of the time: EInvalidOp.

It is one of the floating point exceptions (incidentally exampled at [WayBack] Exceptions: Declaring Exception Types) all inheriting from the [WayBack] EMathError Class:

EMathError is the base class for floating-point math exception classes. EMathError itself is never raised.

The following exceptions descend from EMathError:

[WayBack] Exception	Meaning
[WayBack] EInvalidArgument	Parameter out of range
[WayBack] EInvalidOp	Processor encountered an undefined instruction
[WayBack] EOverflow	Floating-point operation produced result too large to store
[WayBack] EUnderflow	Floating-point operation produced result with no precision
[WayBack] EZeroDivide	Attempt to divide by zero

Run-time exception information is saved in fields provided by [WayBack] EExternal.

Use-after-free

In my first case (which I described in delphi – Invalid floating point operation calling Trunc()), not all input scenarios has been tested in a certain scenario. In a production environment, one of the inputs was really high.

In a later case, the actual cause was not a floating point problem at all, but a use-after-free scenario that overwrite a floating point value with something not so compatible also causing a simple Trunc statement to fail in the same way.

In that case, the production data could never reach the big numbers that failed, so no new tests were needed.

–jeroen