Tue, 11/05/2019 - 14:13
Hi all,
I am trying to import a STEP file provided to me for testing. I was using OpenCascade 7.2.0 until recently, and upgraded to 7.4.0 a few days ago.
The issue I am running into happened in 7.2.0 and still happens in 7.4.0.
I also tried opening the file in FreeCAD. FreeCAD 0.17 opens it, but 0.18 and 0.19 fail to open it.
The STEP file in question was exported from SolidWorks:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION (( 'STEP AP203' ),
'1' );
FILE_NAME ('myStepFile.STEP',
'2019-01-14T10:13:00',
( '' ),
( '' ),
'SwSTEP 2.0',
'SolidWorks 2019',
'' );
FILE_SCHEMA (( 'CONFIG_CONTROL_DESIGN' ));
ENDSEC;THE PROBLEM:
When I import the STEP file (using a STEPCAFControl_Reader) in a DEBUG build of my application, an exception is thrown during the transfer of the document, see these screenshots:
It seems the OrientedEdge is nullptr for some reason, but this hasn't happened to me in many files before.
Now, I am not handling exceptions most of the time, and I could try to do that, though I don't know if that will fix the crash.
I am not sure what is the culprit, and I have trouble working with the file even in FreeCAD. I think a few parts in the file are problematic, I cannot even export them to STEP from FreeCAD.
Nevertheless, I would really like to be able to simply handle any file provided to me, especially if it was exported from something as established as SolidWorks.
Tue, 11/05/2019 - 17:34
You have forgotten attaching the model itself.
Tue, 11/05/2019 - 17:54
Unfortunately, I cannot share the model. It is unfortunately also fairly large, which makes it take a long time for the debugger to break (just unfortunate for me).
I realize there is little to go by here, but I hoped there might be something that someone noticed.
One update:
I can get past the document transfer, by disabling signals:
I tried this after seeing this post: https://stackoverflow.com/questions/57078323/opencascade-crash-when-calling-calling-transfer
The document transfer completes, and I can start working with the shapes. There is still a crash somewhere during this, possibly still corrupted data somewhere, but I need to run it again in debug mode, which will take time, before I can see where it actually breaks.
Wed, 11/06/2019 - 11:34
This doesn't disable signals, but rather enables them, so that NULL dereference throws C++ exception and STEP reader handles them as error while translating specific item.
Although NULL entities in STEP might indicate some problems in file itself, adding NULL checks to OCCT STEP reader is most straightforward solution
(it might be necessary, however, analyzing why they are NULL to possible avoid loosing information).
Making a blind fix without reproducer usually doesn't work, so that the model is needed for registering a bug.
Note that models coming from customers in scope of support program are considered confidential by default,
and you can also send file by contacting Open Cascade to keep it non-public:
https://www.opencascade.com/content/technology-support
Otherwise, you may also try fixing the problem yourself and contribute patch for integration:
https://dev.opencascade.org/index.php?q=home/get_involved
Tue, 11/12/2019 - 12:22
I will post an update.
It seems that some of the geometry in the STEP file is definitely somehow corrupt. This was exported from SolidWorks, and it seems most of the parametric surfaces are exported as Geom_RectangularTrimmedSurface. I run most surfaces through a BRepBuilderAPI_NurbsConvert, and for some reason, during the conversion process of some surfaces, the resulting NURBS has a negative weight, which crashes OpenCascade when it checks the weights when constructing the surface. For now I disabled exceptions in Visual studio as well and it no longer crashes.
I am still interested to find out a robust solution for faulty geometry like this, but I don't have time for that currently and need to push it on the backlog.