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

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 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.
–jeroen