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


Quite some time ago, 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


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

In my first case (which I described in delphi – Invalid floating point operation calling Trunc()), not all input scenarios had 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.

Comments are closed.