openNURBS 8 floating-point invalid operation exception

openNURBS
1

I am getting floating-point invalid operation exceptions using the openNURBS 8 library. The same code runs without issue using the openNURBS 7 library.

I am compiling 64-bit debug using Visual Studio 2017. The exception is turned off by default so you’ll need to enable the exception or check your output window to confirm.

Issue 1 - opennurbs_statics.cpp; line 333

const ON_SubDEdgeSharpness ON_SubDEdgeSharpness::Nan = ON_SubDEdgeSharpness::FromConstant(ON_DBL_QNAN);

The exception occurs inside the FromConstant function when gt/lt operations are performed using the nan value.

opennurbs8-x64-debug-fpinvalidop
opennurbs8-x64-debug-fpinvalidop1920×1168 161 KB

Issue 2 - opennurbs_bounding_box.cpp::ON_BoundingBox::IsNotEmpty(); line 2159

What I do is this:

ONW_Model model = new ONW_Model;
FILE archive_fp = ON::OpenFile(L"C:\Somewhere\v2_HumanHead1.3dm", L"rb");
ON_BinaryFile archive(ON::archive_mode::read3dm, archive_fp);
bool rc = model->model.Read(archive);

It looks to me like ON_BoundingBox::IsNotEmpty() is being called for a bounding box with min=(nan,nan,nan), max=(nan,nan,nan) and this causes a floating-point invalid operation exception.

opennurbs8-x64-debug-fpinvalidop-nanpoint
opennurbs8-x64-debug-fpinvalidop-nanpoint1920×1200 241 KB

Any help appreciated. Thank you.

2

Hi @IanS,

I am not seeing the error using VS2019 or VS2022 with the V142 platform toolset.

I don’t have VS2017 installed. Have you tried VS 2019 or newer?

– Dale

3

Hi Dale,
Thank you for your quick response. I made a mistake. I am using Visual Studio Community 2019 16.11.32. Project properties shown below.

opennurbs8-x64-debug-projectproperties
opennurbs8-x64-debug-projectproperties800×550 41.3 KB

When I run the example_read.exe program, the exception is not observed.

example_read.exe and st7rhino.dll pretty much do the same thing. It is when I call LoadLibrary that the Issue 1 exception occurs and then LoadLibrary returns a zero handle. If I patch the opennurbs code to avoid doing floating point operations on nan values, I get Issue 2 later on downstream. It occurs on many of the provided example files including v2_HumanHead1.3dm.

Thank you for your time looking at this.
IanS

4

Hi Dale,
I am compiling a DLL in VS2019 that statically links to the openNURBS toolkit. The purpose of this dll is to provide a C interface to the openNURBS toolkit which is callable from Delphi programming language.

I have done further testing and have found that when I load the dll from a Visual Studio compiled console application, the exception is not thrown. When I load the same dll from a Delphi compiled console application, the exception is thrown and LoadLibrary returns 0.

I have three very simple projects which can be used to reproduce the issue. I provide the delphi compiled executable as well. The download link is:
https://www.dropbox.com/scl/fi/fguu8yra4z7oceds0m8u8/onTEST.zip?rlkey=25ptet8fgdjodhr2ihc8bosyc&dl=1

The projects are as follows:

  1. onTESTDLL - This is a very simple VS 2019 DLL project that statically links to the openNURBS toolkit.

  2. onTESTEXE - This is a very simple VS2019 console application which calls the functions in onTESTDLL.dll. This does not trigger the exception.

  3. onDELPHIEXE - This is a very simple Delphi XE6 console application which calls the functions in onTESTDLL.dll. This does trigger the exception.

You’ll want to put “v2_HumanHead1.3dm” in your “C:\TEMP” folder before running.

Thanks,
IanS

5

Hi @IanS,

Thanks for the sample. I can repeat what you’re seeing with the Delphi executable.

I honestly don’t know what we can do. From what I’ve read online, Delphi throws an exception when a NaN is put into the FPU. But what do I know.

I guess if you’re building openNURBS, you might editing the offending line of code.

– Dale

6

Hi Dale,
Rather than modify the openNURBS code, I am using the following workaround.

Before loading the openNURBS DLL I execute the following in Delphi:

var
AEM: Math.TArithmeticExceptionMask;
begin
AEM:=Math.GetExceptionMask;
Math.SetExceptionMask(AEM+[exInvalidOp]);

This prevents the floating-point-number hardware from raising the exception.

After unloading the openNURBS DLL I execute the following in Delphi:

Math.ClearExceptions;
Math.SetExceptionMask(AEM);

This clears unraised exceptions and restores the exceptions policy back to what it was before.

Thanks for your help on this.
Ian S

1 Like
7

Hi @IanS,

Thanks for the update; happy you’re moving forward.

Just curious, what are you doing with openNURBS and Delphi?

Thanks,

– Dale