Opencascade crash when calling calling Transfer()

Question

I have tested two cases:

I use STEPCAFControl_Reader then STEPControl_Reader to read my step file but both methods crash when I call STEPCAFControl_Reader::Transfer, repsectively STEPControl_Reader:: TransferRoots.

By using STEPControl_Reader, I displayed a log on my console, then there is a message like this:

1 F:(BOUNDED_SURFACE,B_SPLINE_SURFACE,B_SPLINE_SURFACE_WITH_KNOTS,GEOMETRIC_REPRESENTATION_ITEM,RATIONAL_B_SPLINE_SURFACE,REPRESENTATION_ITEM,SURFACE): Count of Parameters is not 1 for representation_item

EDIT:

There is a null reference inside TransferRoots() method.

const Handle(Transfer_TransientProcess) &proc = thesession->TransferReader()->TransientProcess();
if (proc->GetProgress().IsNull())
{
   //This condition does not exist from the source code
   std::cout << "GetProgress is null" << std::endl;
   return 0;
 }    
Message_ProgressSentry PS ( proc->GetProgress(), "Root", 0, nb, 1 );

My app and FreeCAD crash but if I use CAD Assitant which OCC official viewer, it loads.

Answer 1

It looks like comments already provide an answer to the question - or more precisely answers:

• STEPCAFControl_Reader::ReadFile() returns reading status, which should be checked before calling STEPCAFControl_Reader::Transfer().

• Normally, it is a good practice to put OCCT algorithm into try/catch block and check for OCCT exceptions (Standard_Failure).

• Add OCC_CATCH_SIGNALS at the beginning of try statements (required only on Linux) and OSD::SetSignal(false) within working thread creation to redirect abnormal cases (access violation, NULL dereference and others) to C++ exceptions (OSD_Signal which is subclass of Standard_Failure). This may conflict other signal handlers in mixed environment - so check also documentation of other frameworks used by application.

• If you catch failures like NULL dereference on calling OCCT algorithm with valid arguments - this is a bug in OCCT which is desirable to be fixed in one or another way, even if input STEP file contains syntax/logical errors triggering such kind of issues. Report the issue on OCCT Bugtracker with sufficient information for reproducing bug, including sample files - it is not helpful to developers just saying that OCCT crashes somewhere. Consider also contributing into this open source project by debugging OCCT code and suggesting patches.

• Check STEP file reading log for possible errors in the file itself. Consider reporting an issue to system producing a broken file, even if main file content can be loaded by STEP readers.

It is a common practice to use OSD::SetSignal() within OCCT-based applications (like CAD Assistant) to improve their robustness on non-fatal errors in application/OCCT code. It is more user friendly reporting an internal error message instead of silently crashing.

But it should be noted, that OSD::SetSignal() doesn't guarantee application not being crashed nor that application can work properly after catching such failure - due to asynchronous nature of some signals, the memory can be already corrupted at the moment, when C++ exception has been raised leading to all kinds of undesired behavior. For that reason, it is better not ignoring such kind of exceptions, even if it looks like application works fine with them.

  OSD::SetSignal(false); // should be called ones at application startup
  STEPCAFControl_Reader aReader;
  try
  {
    OCC_CATCH_SIGNALS // necessary for redirecting signals on Linux
    if (aReader.ReadFile (theFilePath) != IFSelect_RetDone) { return false; }
    if (!aReader.Transfer (myXdeDoc)) { return false; }
  }
  catch (Standard_Failure const& theFailure)
  {
    std::cerr << "STEP import failed: " << theFailure.GetMessageString() << "\n";
    return false;
  }
  return true;