In Windows I only get an exception message (access violation) in the report view, no crash in 3 tries.
OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.17505 (Git)
Build type: Release
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)
In Ubuntu debug build I get crash at line 100 of FeatureFillet.cpp.
The line is mkFillet->Build();
mkFillet is of type BRepFilletAPI_MakeFillet, which is an open cascade object.
It crashes even though the function is called inside a try except block. I tried using catch(...), which is a catch all for all exceptions in c++, but still the exception handler isn't called, only the crash happens. I'm not a c++ wizard by any means, but I don't see a way to avoid this type of crash simply by using try/catch blocks no matter even if a catchall type is used.
If found this information in the OCCT documentation:
virtual void BRepFilletAPI_MakeFillet::Build ( )
Builds the fillets on all the contours in the internal data structure of this algorithm and constructs the resulting shape. Use the function IsDone to verify that the filleted shape is built. Use the function Shape to retrieve the filleted shape. Warning The construction of fillets implements highly complex construction algorithms. Consequently, there may be instances where the algorithm fails, for example if the data defining the radius of the fillet is not compatible with the geometry of the initial shape. There is no initial analysis of errors and they only become evident at the construction stage. Additionally, in the current software release, the following cases are not handled:
the end point of the contour is the point of intersection of 4 or more edges of the shape, or
the intersection of the fillet with a face which limits the contour is not fully contained in this face.
Reimplemented from BRepBuilderAPI_MakeShape.
I don't know if either of the 2 documented cases that are not handled apply in this particular case, but my guess would be the 2nd one is the issue. But that is only a guess. One way FreeCAD could prevent this crash then would be to check to see if one of these cases are present before calling Build(), but this is beyond my meager skills.
I wonder if it would work to call OCCT library functions via a child process? If this could be done, then perhaps only the child process would crash and not FreeCAD? Likely, the idea has been already considered and dismissed at some point, but if it could work I can think of a number of benefits: 1) FreeCAD is much more stable against crashes; 2) Operations that are taking too long could be canceled by killing the child process; 3) There could be ways to use this for multi-threading, perhaps by spawning multiple instances of the child process, perhaps by allowing the user to continue using FreeCAD while the operation is pending.