-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash when unioning toruses (upstream OCC bug) #5632
Comments
The example file for this bug isn't available anymore. |
@luzpaz can skip forum discussion now I guess. |
No crash when making a union with
|
@wwmayer can you reproduce as well ? |
On my old system I had a self-compiled OCCT 7.6 and there it worked. See my comment from 2021-12-12 14:45 |
No crash for me. Neither on:
or
|
This should be closed by now as either "cannot reproduce" or "resolved on updating dependency" |
Nice. Closing. |
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
The text was updated successfully, but these errors were encountered: