Question

我已经测试了两种情况：

我先使用STEPCAFControl_Reader，然后使用STEPControl_Reader读取我的步骤文件，但是当我分别调用STEPCAFControl_Reader :: Transfer和STEPControl_Reader :: TransferRoots时，这两种方法都会崩溃。

通过使用STEPControl_Reader，我在控制台上显示了一个日志，然后出现了这样的消息：

1 F：（BOUNDED_SURFACE，B_SPLINE_SURFACE，B_SPLINE_SURFACE_WITH_KNOTS，GEOMETRIC_REPRESENTATION_ITEM，RATIONAL_B_SPLINE_SURFACE，REPRESENTATION_ITEM，SURFACE）：representation_item的参数计数不是1

编辑：

TransferRoots（）方法内没有空引用。

state = {
    user : null
}

我的应用程序和FreeCAD崩溃，但如果我使用OCC官方查看器的CAD助手，则会加载它。

Answer 1

评论似乎已经为问题提供了答案-更准确地说，是答案：

STEPCAFControl_Reader :: ReadFile（）返回读取状态，应在调用 STEPCAFControl_Reader :: Transfer（）之前对其进行检查。
通常，将OCCT算法放入 try / catch 块并检查OCCT异常（ Standard_Failure ）是一种好习惯。
< / li>
在try语句的开始处添加 OCC_CATCH_SIGNALS （仅在Linux上必需），并在工作线程创建中添加 OSD :: SetSignal（false）以重定向异常情况（访问冲突，NULL取消引用等）到C ++异常（ OSD_Signal ，它是 Standard_Failure 的子类）。这可能会在混合环境中与其他信号处理程序发生冲突-因此也请查看应用程序使用的其他框架的文档。
如果在调用带有有效参数的OCCT算法时遇到诸如NULL取消引用之类的失败-这是OCCT中的 bug ，需要固定为一个或多个另一种方式，即使输入的STEP文件包含触发此类问题的语法/逻辑错误。在OCCT Bugtracker上报告此问题，并提供足够的信息来重现错误，包括样本文件-对于仅说OCCT崩溃的地方的开发人员没有帮助。考虑通过调试OCCT代码和建议补丁程序也为这个开源项目做出贡献。
检查STEP文件读取日志中文件本身是否可能存在错误。考虑将问题报告给产生损坏文件的系统，即使主文件内容可以由STEP阅读器加载。

通常的做法是在基于OCCT的应用程序（如CAD Assistant）中使用 OSD :: SetSignal（）来提高其对应用程序/ OCCT代码中非致命错误的鲁棒性。报告内部错误消息对用户更友好，而不是默默地崩溃。

但是应该注意， OSD :: SetSignal（）不能保证应用程序不会崩溃，也不能保证应用程序在捕获到此类故障后无法正常工作-由于某些信号的异步特性，当引发C ++异常导致各种不良行为时，内存可能已经被破坏。因此，最好不要忽略此类异常，即使看起来应用程序可以很好地使用它们。

  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;

调用Transfer（）时Opencascade崩溃

1 个答案: