Archived issue #0032931
Crash in ChFi3d_IsInFront when no face was found
Description
(This problem was seen with the version bundled with FreeCAD 0.20.28445 but can be reproduced easily with the master version directly from OCCT)
The ChFi3d_IsInFront code is currently not handling all the combinations correctly. For example, if `if(fd1->IndexOfS2() == fd2->IndexOfS2())` is true, it can happen that the `TopoDS::Face(DStr.Shape(fd1->Index(jf1)))` returns a Face with entity == NULL. The subsequent usage of this NULL face in `BRep_Tool::Parameters( Vtx, face )` will then cause a segfault.
More information (including how it was debugged) can be found at:
* https://github.com/FreeCAD/FreeCAD/issues/6625#issuecomment-1094139670
* https://forum.freecadweb.org/viewtopic.php?p=584239#p584239
The ChFi3d_IsInFront code is currently not handling all the combinations correctly. For example, if `if(fd1->IndexOfS2() == fd2->IndexOfS2())` is true, it can happen that the `TopoDS::Face(DStr.Shape(fd1->Index(jf1)))` returns a Face with entity == NULL. The subsequent usage of this NULL face in `BRep_Tool::Parameters( Vtx, face )` will then cause a segfault.
More information (including how it was debugged) can be found at:
* https://github.com/FreeCAD/FreeCAD/issues/6625#issuecomment-1094139670
* https://forum.freecadweb.org/viewtopic.php?p=584239#p584239
Steps to reproduce
# get most recent OCCT
$ cd /tmp/
$ git clone https://git.dev.opencascade.org/repos/occt.git OCCT
# get build dependencies based on opencascade package in the Debian package source (deb-src) repository. will most likely work differently on whatever Distro you are using
$ sudo apt build-dep opencascade
# build everything (I only have 4 cores - you might change it if you are not working on a system with a 10 year old CPU)
$ cd OCCT
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DCMAKE_VERBOSE_MAKEFILE=true && make -j4
# prepare reproducer script
$ cd /tmp/OCCT/
$ cat > test.script << "EOF"
# load the brp, get edges and then try to add fillet on the problematic edges
pload ALL
restore /tmp/Attachment 1 (BRP) b
explode b E
blend b2 b 1 b_10 1 b_18 1 b_19 1 b_20 1 b_21 1 b_17
# REMARK: following line is also good enough to cause a crash (inner two edges of the L shape). But it is not the operation from the original reporter:
# blend b2 b 1 b_19 1 b_20
EOF
# start DRAWEXE shell
# usually I would have done it like that. But it is then not 100% reproducible due to various system effects.
# So I just use gdb in the actual command to improve my live and make it 100% reproducible
#$ LD_LIBRARY_PATH=/tmp/OCCT/build/lin64/gcc/libd/ CASROOT=/tmp/OCCT ./build/lin64/gcc/bind/DRAWEXE -f test.script
$ LD_LIBRARY_PATH=/tmp/OCCT/build/lin64/gcc/libd/ CASROOT=/tmp/OCCT gdb -q --ex run --args ./build/lin64/gcc/bind/DRAWEXE -f test.script
$ cd /tmp/
$ git clone https://git.dev.opencascade.org/repos/occt.git OCCT
# get build dependencies based on opencascade package in the Debian package source (deb-src) repository. will most likely work differently on whatever Distro you are using
$ sudo apt build-dep opencascade
# build everything (I only have 4 cores - you might change it if you are not working on a system with a 10 year old CPU)
$ cd OCCT
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DCMAKE_VERBOSE_MAKEFILE=true && make -j4
# prepare reproducer script
$ cd /tmp/OCCT/
$ cat > test.script << "EOF"
# load the brp, get edges and then try to add fillet on the problematic edges
pload ALL
restore /tmp/Attachment 1 (BRP) b
explode b E
blend b2 b 1 b_10 1 b_18 1 b_19 1 b_20 1 b_21 1 b_17
# REMARK: following line is also good enough to cause a crash (inner two edges of the L shape). But it is not the operation from the original reporter:
# blend b2 b 1 b_19 1 b_20
EOF
# start DRAWEXE shell
# usually I would have done it like that. But it is then not 100% reproducible due to various system effects.
# So I just use gdb in the actual command to improve my live and make it 100% reproducible
#$ LD_LIBRARY_PATH=/tmp/OCCT/build/lin64/gcc/libd/ CASROOT=/tmp/OCCT ./build/lin64/gcc/bind/DRAWEXE -f test.script
$ LD_LIBRARY_PATH=/tmp/OCCT/build/lin64/gcc/libd/ CASROOT=/tmp/OCCT gdb -q --ex run --args ./build/lin64/gcc/bind/DRAWEXE -f test.script
Public activity
11 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Author.
[revision removed]
Detailed log of new commits:
Author: Charlemagne Lasse
Date: Wed Apr 13 11:54:30 2022 +0200
0032931: Modeling Algorithm - In PerformIntersectionAtEnd Avoid crash when no face was found
The PerformIntersectionAtEnd code is currently not handling all the faces
correctly. If it retrieves Face[0] as F, it can happen that the previously
ran code didn't actually retrieve any faces in this array at all.
For example when:
* "if (nface==3)" is true
- "if (!findonf1)" is true (doesn't assign any faces to this array)
- "if (!findonf2)" is true (doesn't assign any faces to this array)
- "if (state == ChFiDS_OnSame)" is not true (because it is
ChFiDS_AllSame)
- "if (findonf1 && !isOnSame1)" cannot be true (see above, but would
handle faces)
- "if (findonf2 && !isOnSame2)" cannot be true (see above, but would
handle faces)
- "if (isOnSame2)" is false (but would also handle faces)
Since no faces were assigned here, F would be a NULL face. As result, the
function will crash when trying to access the Surface behind the face via
`BRep_Tool::Surface(F);`.
While the best approach would be to identify the implementation bug in the
algorithm behind PerformIntersectionAtEnd, a check + exception is used
instead because the actual algorithm is not known.
Signed-off-by: Charlemagne Lasse <[email removed]>
[revision removed]
Detailed log of new commits:
Author: Charlemagne Lasse
Date: Wed Apr 13 11:54:30 2022 +0200
0032931: Modeling Algorithm - In PerformIntersectionAtEnd Avoid crash when no face was found
The PerformIntersectionAtEnd code is currently not handling all the faces
correctly. If it retrieves Face[0] as F, it can happen that the previously
ran code didn't actually retrieve any faces in this array at all.
For example when:
* "if (nface==3)" is true
- "if (!findonf1)" is true (doesn't assign any faces to this array)
- "if (!findonf2)" is true (doesn't assign any faces to this array)
- "if (state == ChFiDS_OnSame)" is not true (because it is
ChFiDS_AllSame)
- "if (findonf1 && !isOnSame1)" cannot be true (see above, but would
handle faces)
- "if (findonf2 && !isOnSame2)" cannot be true (see above, but would
handle faces)
- "if (isOnSame2)" is false (but would also handle faces)
Since no faces were assigned here, F would be a NULL face. As result, the
function will crash when trying to access the Surface behind the face via
`BRep_Tool::Surface(F);`.
While the best approach would be to identify the implementation bug in the
algorithm behind PerformIntersectionAtEnd, a check + exception is used
instead because the actual algorithm is not known.
Signed-off-by: Charlemagne Lasse <[email removed]>
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
According to https://dev.opencascade.org/get_involved, I should do following: "Push your change to Git repository in branch with name starting with "CR" followed by the issue Id, then switch the issue to Resolved.". But I don't have any button to do this.
EDIT: Problem was solved by azv
EDIT: Problem was solved by azv
General comment - `Standard_Failure` is the base class in hierarchy of exceptions in OCCT, and is never expected to be thrown directly.
It is expected to throw some related exception subclass - like `Standard_NullObject` or `Standard_ProgramError`.
It is expected to throw some related exception subclass - like `Standard_NullObject` or `Standard_ProgramError`.
Branch [archived branch] has been updated forcibly by Author.
[revision removed]
[revision removed]
I was asked to bump this ticket. What can/should be done here to continue forward?
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
I attach shape with proper name.
Attachment 2 (BREP) (13,958 bytes)
Reviewed. Jenkins job is:
http://jenkins-test-occt/view/CR32931-master-aml/view/COMPARE/
http://jenkins-test-occt/view/CR32931-master-aml/view/COMPARE/
Combination -
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18736.560000000623 / 18755.550000000607 [-0.10%]
Products
Total CPU difference: 11708.410000000114 / 11723.710000000106 [-0.13%]
Windows-64-VC14:
OCCT
Total CPU difference: 20637.375 / 20721.125 [-0.40%]
Products
Total CPU difference: 13299.6875 / 13249.9375 [+0.38%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18736.560000000623 / 18755.550000000607 [-0.10%]
Products
Total CPU difference: 11708.410000000114 / 11723.710000000106 [-0.13%]
Windows-64-VC14:
OCCT
Total CPU difference: 20637.375 / 20721.125 [-0.40%]
Products
Total CPU difference: 13299.6875 / 13249.9375 [+0.38%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]