For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

Crash on STEP import from SolidWorks?

Nathaniel Essenberg's picture
Forums: 

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:

a.jpg

b.jpg

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.

Attachments: 
Kirill Gavrilov's picture

You have forgotten attaching the model itself.
 

Nathaniel Essenberg's picture

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:

#define OCC_CATCH_SIGNALS
OSD::SetSignal(false);

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.

Kirill Gavrilov's picture

I can get past the document transfer, by disabling signals:

OSD::SetSignal(false);

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

Unfortunately, I cannot share the model.

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

Nathaniel Essenberg's picture

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.

Contact us

Attention: DO NOT use this form for all kind of request for the removal of your personal data. Please follow this link for such cases.