openNURBS 6 crash in VS2019 16.7 with Address Sanitier flag on

Hi Experts,
I am testing openNURBS toolkit with Address Sanitizer (which is available start from VS2019 16.7 (Read the link of more details if you have interests https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/);

One model reported “allocation size too big” issue when load it with openNURBS toolkit. Can you help take a look to see why this happens?

The sample project used to reproduce this issue is uploaded, to verify this please

  1. Update VS2019 to 16.7+ (I am using 16.7.3)
  2. Ignore the 0xC000005 access violation exception during startup, this is expected according to Win ASan. In visual studio Exceptions Settings, you can uncheck this exception type in Win32 Exceptions dialog.
  3. Build and Run the example_read project

opennurbs_6.1.18014.22401-2.zip (6.3 MB)

Hi @dannyzhu,

If you disable the Address Sanitizer, are you able to read the 3dm file?

I don’t believe I have the new Address Sanitizer installed. I’ll try to find time to look into this in the next few days.

Thanks,

– Dale

At the time of the error, T-splines code is reading “userdata”.

image

It is most likely, the T-splines code that writes or reads this userdata contains a bug. I do not have access this code so I cannot comment further on what this bug might be.

It is possible that part of the file has been corrupted. I cannot test this because I don’t know the structure of the T-splines user data chunk and so I don’t have enough information to inspect the internal CRCs we put at the end of each chunk that T-splines wrote.

It appears ...\opennurbs_6.1.18014.22401-2\example_read\HoleyCube.3dm is the file in question.

When this file is read without T-splines present, no errors occur. When T-splines is not present, the entire chunk is read as unknown userdata. All of the blocks that I have enough information to test have valid CRCs, so I will speculate that file corruption is less likely than a bug in the T-spines code.

All this said, I cannot rule out there is a bug in the opennurbs code, but I cannot do any further investigation because I don’t have access to the T-splines code.

The next step I would suggest to carefully watch that T-splines user data chunk being written in the debugger and take notes on the chunk sizes, offsets, and CRCs. Then carefully watch T-splines user data chunk being read and verify that the reading is exactly in sync with what was written.

– Dale Lear (There are 2 Dales - Dale Fugier and myself.)

CORRECTION - I see that the T-splines user data code is included in the zip file you posted (atf_tspline_user_data.cpp/h). I apologize for missing this during my first inspection. I’ll ask somebody here to look into it further.

Hi @dale,
If disable ASan, the model can be read successfully.
Thanks,
Danny

Thank you @dalelear!

  • Start the Visual Studio Insaller
  • Select Modify… for your vs2019
  • Select C++ AddressSanitizer under Debugging and testing
  • Install modification
  • Open OpenNURBS solution
  • Open properties for project you want to use Address Sanitizer on
  • Under C/C++ > General enable Address Sanitizer
  • Rebuild

For AddressSanitizer runtime to find its “symbolizer.” and calls out to llvm-symbolizer.exe, you need add C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\bin\Hostx64\x64 to your user path.

The AddressSanitizer flag and required link setting is configured in the sample project already.

Hi Experts, any updates on this issue?

@dannyzhu,

Did you see this above?

It is most likely, the T-splines code that writes or reads this userdata contains a bug. I do not have access this code so I cannot comment further on what this bug might be.

– Dale

Hi @dale, The uploaded sample code contains the userdata codes. @dalelear confirmed this, see below: