Segfault after a simple Chamfer about freecad

[FlachyJoe]

The bug is here:
https://github.com/Open-Cascade-SAS/OCCT/blob/4c8faa5e2dd0d3e4bd7039c908016d8204889c09/src/BRep/BRep_Tool.cxx#L322-L325

  // find the representation
  const BRep_TEdge* TE = static_cast<const BRep_TEdge*>(E.TShape().get());
  BRep_ListIteratorOfListOfCurveRepresentation itcr(TE->Curves());

There is no guard against TE==nullptr

[bgbsww]

The problem is that the issue still exists, it just gets weirder. If the code always does -0.001 and you set the size 2.001 then the segfault still happens; you've just changed the triggering value. I think the two viable paths here are for the opencascade bug to be fixed (don't hold your breath, but it is the correct path), or to identify places where the bug is likely to be triggered and avoid them. That's likely to be both tricky and expensive in terms of CPU usage.

If I get some time, post-Toponaming, I might walk down into the OCCT code and see if there's at least a solution to be suggested, but for now it's out of scope for me. I'll hope for someone else's smart solution.

[xtemp09]

The backtrace provided in the issues #8179 and #10472 (the latter was closed as duplicate) is really close to this one.

[maxwxyz]

Is this a duplicate of the already solved #14194
Please let me know.

[leoheck]

Considering my provided log, the message about the Invalid edge link: is present in it.

[maxwxyz]

@chennes @bgbsww the similar issue was closed with reference to db48a78 but there still seems an issue with Invalid edge link

[bgbsww]

So, there is an issue with naming of edges that triggers the Invalid edge Link messages, and I have a fix for that working its way though. This is a different issue: If you change the example from 1 to 0.75 or 1.25 or even 1.5 everything is fine. At 2.0 the chamfer is invalid, but as leoheck points out, propogating the fault up from opencascade and crashing the app is the wrong thing to do. I'm looking to find the right solution now.

Further: this is proving difficult to work around. At 2.5 you correctly get a refusal to chamfer. It is just the exact case of 2.0 that triggers an underlying error in OpenCascade. So far, I can't find a defense in FC against it. Other exact chamfers don't cause it; suspicious that this is ultimately about multiple shapes coinciding at a point.

https://forum.freecad.org/viewtopic.php?t=56437 Maybe? Changing the chamfer to a fillet also crashes at exactly 2.0, but not any other value. And trying the same thing in an official Link Browser version of FreeCAD as well as in the 0.21.1 release also result in the crash.

So, this is an OpenCascade bug that I don't think I can fix.

[leoheck]

ultimately about multiple shapes coinciding at a point.

I've noticed that when things align to a point/edges... strange things used to happen at that time.
Sometimes, in the past, it just doesn't perform the chamfer/fillet, sometimes like on this version, it crashes.

It used to happen exactly the way @bgbsww described...
Chamfer/fillets work from a small range of values... like 0.25, 0.5, then, close to another edge/point, for instance, at 1 mm or sometimes 2 mm (mostly this happens to me on decimals, it may be a coincidence tho) it fails... then going bigger, like 1.2, 1.4, 1.5, or even bigger like 4 mm it starts to work again (but sometimes at this case it renders an odd shape, like an arc above the intersection of the problematic edges/points.

[leoheck]

So, this is an OpenCascade bug that I don't think I can fix.

Yeah, is it possible to add something like -0.001 or -0.01 under the hood to see if this gets improved? Maybe most of the time people use decimals, and then if I add 1 mm ... under the hood it is going to be 1 - 0.001 and it may not break the tool.

This is ugly, I agree, but it would be worth a lot if the tool could not crash when doing chamfers/fillets.

[leoheck]

@FlachyJoe is this a known bug that has persisted for ages or did you find it now? What are the chances to get it fixed there? Is there any way to detect this null pointer from the Freecad before it crashes?

[bgbsww]

I'm gonna guess that it's been known for ages. I can state confidently that OCCT doesn't care about bugs that affect interactive use of the core; they may fix them eventually out of chasing correctness, but since in a non-interactive usage you just nudge the value a touch and move on, there isn't a strong motivation. FreeCAD doesn't generate any revenue to pay their costs. I don't say this to condemn them, just to make it clear the challege they face. OpenCascade has to try to continue to exist, and FreeCAD isn't part of that.

With that out of the way, the clue FlachyJoe gives here is good - the question is can we replicate the call in the first line, and check it for null, and how expensive it is to call that. If so, we can avoid the segfault.

I'm supposed to have my blinders on, but I know I'm gonna go look at that question in a couple hours. Bad me.

[bgbsww]

Nothing in ShapeAnalysis_Edge will predetect this failure. I have not yet tried shape healing. I've also not yet searched the OCCT source code for all places that cast a TShape into a TEdge to try to find other APIs that we might use.

[FlachyJoe]

@leoheck I've set up a FreeCAD-dev + OCCT-dev debug suite.

[leoheck]

@bgbsww found some other places with the pattern @FlachyJoe presented:

grep -n -R "static_cast<const BRep_TEdge\*>(E.TShape()"

[leoheck]

And also, a similar list is used in other places too:

grep -n -R "BRep_ListIteratorOfListOfCurveRepresentation itcr(TE->Curves())"

[FlachyJoe]

@leoheck I signed the OCCT contributor license agreement and I'm waiting for a PR access to OCC git.
Nevertheless, patch won't be backported and we have to deal with the buggy library.

[leoheck]

That is cool @FlachyJoe. It would be awesome if we could have this improved on the new 1.0 release. But I have no hope haha.

Nevertheless, patch won't be backported and we have to deal with the buggy library.

Yeah, I understand. Do you know if it is possible to somehow check if this situation from Freecad? Not sure if there is a way to re/create this list that is being used above and if it is empty then we could somehow prevent the crash before it happens?

[bgbsww]

Oh, that's great news if you can submit PRs. Also, looking at the source code, every single place that E.TShape.get() is called, it immediately is used as a pointer, so the null deref segfault will occur.

However! Maybe we can abuse one of the vertex calls like BRep_Tool::Pnt(const TopoDS_Vertex& V) by deliberately miscasting the edge into a vertex and taking advantage of the null check that is in there. I feel dirty just suggesting this, but library workarounds are library workarounds.

[FlachyJoe]

@bgbsww have you try void BRepFilletAPI_MakeChamfer::Simulate ( const Standard_Integer IC )? IC is contour index.

[bgbsww]

Yeah, no on that point trick. Because it isn't our edge that is blowing up. It is a newedge created by ChFi3d_Builder::StartSol and it is null because neither of the 2 (!) edges of the newface match the E value passed in. I think this is the algorithm to go through in detail to determine exactly the cause. I am suspicious that another case initializes with TopoDS_Edge newedge = E;
which would at least defend the null pointer. But ultimately, it seems to be about a Vertex and a "c1obstacle", and that needs deeper analysis.

I have not tried Simulate. I'm going to stop looking at this for now, other things I should be looking at.