Issue imported from https://tracker.freecad.org/view.php?id=2204
- Reporter: biogeo
- Date submitted: 7/30/2015
- FreeCAD version: 0.15
- Category: Bug
- Status: resolved
- Tags: #pending, #ready-for-migration, OCC Bug, OCC NotOnRoadmap, upstream
Original report text
When using the part workbench to union two toruses, in certain situations FreeCAD will appear to enter an infinite loop, during which it gradually consumes more and more RAM until the system slows to a crawl and the only solution is to kill the process.
I have found this to occur under the following conditions:
- For both toruses, Radius1 == Radius2, and they are also equal between the two toruses.
- For both toruses, Angle3 == 90 degrees, i.e., they are both a "quarter donut".
- The two toruses are positioned to share a circular face.
Depending on the relative angle between the planes in which the toruses lie, the union operation will sometimes work correctly, sometimes "succeed" but produce an unexpected result (e.g., only three circular faces with no torus components), and sometimes produce the infinite loop condition described above.
Steps to reproduce
- Open a new file and go to the Part workbench
- Create a torus "Torus" with Radius1=2mm, Radius2=2mm, Angle3=90
- Create a second torus "Torus001" with Radius1=2mm, Radius2=2mm, Angle3=90
- Rotate Torus001 90 degrees about the z-axis. The two together should look like a single torus with Angle3=180.
- Select Torus and Torus001 and use the Union tool.
FreeCAD enters an infinite loop gradually allocating more and more RAM until the system slows to a crawl and the process must be killed.
The attached file is the result of steps 1-4. Opening this file in a new FreeCAD session and running Union on the two toruses reliably crashes FreeCAD on my system.
Other bug information
- Priority: normal
- Severity: crash
- Category: Bug
- OS: Linux Mint 13 Maya
- Updated: 1/24/2022
- Fixed in version: 0.2
Discussion from Mantis ticket
Comment by biogeo 2015-07-30 20:25
Forgot to include as additional information:
OS: Linux Mint 13 Maya
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.15.4671 (Git)
Branch: releases/FreeCAD-0-15
Hash: 244b3ae
Python version: 2.7.3
Qt version: 4.8.1
Coin version: 3.1.3
OCC version: 6.8.0.oce-0.17
Comment by @wwmayer 2016-02-28 18:32
That's clearly an OpenCascade bug which we are not able to fix.
Comment by jmaustpc 2016-03-01 15:17
It eventually crashes FreeCAD here, with the OCE from tanderson, OCE patches over OCC 6.9.1
OS: Ubuntu 12.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6523 (Git)
Build type: Release
Branch: master
Hash: ecd6517
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 3.1.3
OCC version: 6.9.1.oce-0.18-dev
Comment by @luzpaz 2017-01-13 17:12
Does this issue persist in OCC 7.x ?
If so Is there an open upstream bug we can link to?
Comment by @luzpaz 2017-06-10 19:54
biogeo can you re-up the attachment? We restored recently from a backup after an issue we had with th tracker and some attachments like yours didn't make it.
Comment by @luzpaz 2017-08-21 11:01
jmaustpc do you mind testing this with OCC7.1 ?
Comment by @wwmayer 2017-09-02 10:43
Attached is a file that shows the behaviour with occ6.8 where the applications eats all memory.
With occ7.2 it now returns immediately but the shape is invalid. On the other hand in practise such a shape doesn't make too much sense anyway.
Comment by @luzpaz 2018-05-30 16:05
Needs to be tested with OCC7.3
Comment by @luzpaz 2019-02-27 21:57
wmayer can you reproduce in OCC7.3
Comment by@wwmayer 2019-02-28 10:22
Yes, the behaviour with OCC7.3 is the same as with 7.2
Comment by@wwmayer 2021-12-12 14:44
With OCC7.4 and 7.5 still invalid shapes are created but with 7.6 finally a correct shape is built.
Comment by @wwmayer 2021-12-12 14:45
Needs to be built with OCC 7.6
Issue imported from https://tracker.freecad.org/view.php?id=2204
Original report text
When using the part workbench to union two toruses, in certain situations FreeCAD will appear to enter an infinite loop, during which it gradually consumes more and more RAM until the system slows to a crawl and the only solution is to kill the process.
I have found this to occur under the following conditions:
Depending on the relative angle between the planes in which the toruses lie, the union operation will sometimes work correctly, sometimes "succeed" but produce an unexpected result (e.g., only three circular faces with no torus components), and sometimes produce the infinite loop condition described above.
Steps to reproduce
FreeCAD enters an infinite loop gradually allocating more and more RAM until the system slows to a crawl and the process must be killed.
The attached file is the result of steps 1-4. Opening this file in a new FreeCAD session and running Union on the two toruses reliably crashes FreeCAD on my system.
Other bug information
Discussion from Mantis ticket
Comment by biogeo 2015-07-30 20:25
Forgot to include as additional information:
OS: Linux Mint 13 Maya
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.15.4671 (Git)
Branch: releases/FreeCAD-0-15
Hash: 244b3ae
Python version: 2.7.3
Qt version: 4.8.1
Coin version: 3.1.3
OCC version: 6.8.0.oce-0.17
Comment by @wwmayer 2016-02-28 18:32
That's clearly an OpenCascade bug which we are not able to fix.
Comment by jmaustpc 2016-03-01 15:17
It eventually crashes FreeCAD here, with the OCE from tanderson, OCE patches over OCC 6.9.1
OS: Ubuntu 12.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6523 (Git)
Build type: Release
Branch: master
Hash: ecd6517
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 3.1.3
OCC version: 6.9.1.oce-0.18-dev
Comment by @luzpaz 2017-01-13 17:12
Does this issue persist in OCC 7.x ?
If so Is there an open upstream bug we can link to?
Comment by @luzpaz 2017-06-10 19:54
biogeo can you re-up the attachment? We restored recently from a backup after an issue we had with th tracker and some attachments like yours didn't make it.
Comment by @luzpaz 2017-08-21 11:01
jmaustpc do you mind testing this with OCC7.1 ?
Comment by @wwmayer 2017-09-02 10:43
Attached is a file that shows the behaviour with occ6.8 where the applications eats all memory.
With occ7.2 it now returns immediately but the shape is invalid. On the other hand in practise such a shape doesn't make too much sense anyway.
Comment by @luzpaz 2018-05-30 16:05
Needs to be tested with OCC7.3
Comment by @luzpaz 2019-02-27 21:57
wmayer can you reproduce in OCC7.3
Comment by@wwmayer 2019-02-28 10:22
Yes, the behaviour with OCC7.3 is the same as with 7.2
Comment by@wwmayer 2021-12-12 14:44
With OCC7.4 and 7.5 still invalid shapes are created but with 7.6 finally a correct shape is built.
Comment by @wwmayer 2021-12-12 14:45
Needs to be built with OCC 7.6