View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004561||Path||Bug||public||2021-02-11 15:05||2021-02-23 07:59|
|Summary||0004561: OpenCamLib (OCL) raises an error on incorrect tool attributes and causes FreeCAD segfault|
The sample file requires the legacy tools to be enabled but appears to be related to passing incorrectly defined tools to OCL.
FreeCAD: /home/brad/opencamlib/src/cutters/ballcutter.cpp:41: ocl::BallCutter::BallCutter(double, double): Assertion `length>0.0' failed.
Aborted (core dumped)
Tool type: Engraver
FreeCAD: /home/brad/opencamlib/src/cutters/conecutter.cpp:46: ocl::ConeCutter::ConeCutter(double, double, double): Assertion `center_height > 0.0' failed.
Aborted (core dumped
|Steps To Reproduce||Open the cone crasher file. Change the surface operation to use one of the other tools and recompute.|
|Additional Information||May not affect all platforms.|
Known to crash on Mint and Fedora
We don't plan to fix legacy tools to prevent bad user data but handling of the OCL error should be fixed
|Tags||No tags attached.|
|FreeCAD Information||OS: Linux Mint 20 (i3/i3)|
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23964 +1 (Git)
Build type: Unknown
Branch: (HEAD detached at upstream/pr/4383)
Python version: 3.8.5
Qt version: 5.12.8
Coin version: 4.0.0
OCC version: 7.3.0
Locale: English/United States (en_US)
cone-crasher.FCStd (224,307 bytes)
||C++ assert() will cause a core dump unless NBEBUG is set. That may need doing for release builds.|
||The pull request has been merged, so this can be closed, correct?|
The PR I provided fixed two specific errors in FC which were triggering coredumps. The question remains, is this error trap outcome desirable in a stable release or should it be trapped/handled differently.
If there is a future error condition is discovered, is it desirable that the user gets faced with a core dump?
This was clearly intended as debugging outcome in OCL and there is a variable to turn it off. Since OLC is currently compiled outside of FC and to all intents and purposes has no active developer this cannot be fixed from FC.
One option would be to fork OCL into FC tree and detect the error condition in a more contorlled manner or submit a PR to OLC if that is preferable.
In short the PR fixed a local bug triggering an instance of the problem, it does not fix the problem.
|2021-02-11 15:05||sliptonic||New Issue|
|2021-02-11 15:05||sliptonic||File Added: cone-crasher.FCStd|
|2021-02-11 17:23||fremen||Note Added: 0015325|
|2021-02-15 09:52||fremen||Note Added: 0015346|
|2021-02-22 21:37||StefanBruens||Note Added: 0015419|
|2021-02-23 07:59||fremen||Note Added: 0015421|