Archived issue #0032444
BRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine
Description
Using OCCT 7.5.2 with the patch for #0029645 and #0031147
When trying to build a pipe with the provided spine, profiles and .tcl file I get a crash in C++ and in DRAW, with the following error in DRAW:
An exception was caught 0x555b1fa4b5c0 : OSD_SIGSEGV: SIGSEGV 'segmentation violation' detected. Address 60
I am using "DT_ShapeDivide" with a tolerance of 0.001 on the spine, "setsweep -DT" and "buildsweep r -C -S".
When trying to build a pipe with the provided spine, profiles and .tcl file I get a crash in C++ and in DRAW, with the following error in DRAW:
An exception was caught 0x555b1fa4b5c0 : OSD_SIGSEGV: SIGSEGV 'segmentation violation' detected. Address 60
I am using "DT_ShapeDivide" with a tolerance of 0.001 on the spine, "setsweep -DT" and "buildsweep r -C -S".
Steps to reproduce
test bugs modalg_7 bug32444
Public activity
18 archived notes
Participants are labeled by their role within this record.
The problem is still reproduced with OCCT 7.5.3.
In the function BRepFill_TrimShellCorner::ChooseSection in the file src/BRepFill/BRepFill_TrimShellCorner.cxx two edges, FirstEdge and LastEdge, are initialized with the result of the function FindEdgeCloseToBisectorPlane.
But in our case FindEdgeCloseToBisectorPlane fails and LastEdge is null.
LastEdge is then used without being tested for nullity, which causes the crash.
The same problem happens for #0032445
And for #0032446 it is FirstEdge that is null.
This bug #0031041 is also potentially related.
I suppose a possible fix could be to check that FirstEdge and LastEdge are not null before using them.
But what makes FindEdgeCloseToBisectorPlane fail? It is some criteria of the spine? Can the situation be detected upstream?
In the function BRepFill_TrimShellCorner::ChooseSection in the file src/BRepFill/BRepFill_TrimShellCorner.cxx two edges, FirstEdge and LastEdge, are initialized with the result of the function FindEdgeCloseToBisectorPlane.
But in our case FindEdgeCloseToBisectorPlane fails and LastEdge is null.
LastEdge is then used without being tested for nullity, which causes the crash.
The same problem happens for #0032445
And for #0032446 it is FirstEdge that is null.
This bug #0031041 is also potentially related.
I suppose a possible fix could be to check that FirstEdge and LastEdge are not null before using them.
But what makes FindEdgeCloseToBisectorPlane fail? It is some criteria of the spine? Can the situation be detected upstream?
I added a patch suggestion.
Jerome, does your patch with NULL-checks allows to produce expected result, or only protects from the crash?
It only protects from the crash.
I believe the root of the problem is that FindEdgeCloseToBisectorPlane fails. Is it because of the spine?
Is there a way to adapt the tolerance parameter of DT_ShapeDivide to the spine?
I believe the root of the problem is that FindEdgeCloseToBisectorPlane fails. Is it because of the spine?
Is there a way to adapt the tolerance parameter of DT_ShapeDivide to the spine?
Dear Participant, on attached profiles and spine you can recieve correct result, when do not use '-C' or '-R' parameters in 'buildsweep' command (resulting shape you can see on the attached Attachment 3 (PNG))
I also attach script to recieve result on Attachment 3 (PNG)
Dear Commenter 1, thank you for your feedback.
Not using the '-C' or '-R' parameters in 'buildsweep' only works properly if enough profiles are given according to the spine, otherwise the pipe may be distorted. So in order to apply this in a generic pipe making function, I will have to detect situations when this is applicable.
Regarding the crash, do you plan on releasing a fix?
Not using the '-C' or '-R' parameters in 'buildsweep' only works properly if enough profiles are given according to the spine, otherwise the pipe may be distorted. So in order to apply this in a generic pipe making function, I will have to detect situations when this is applicable.
Regarding the crash, do you plan on releasing a fix?
Dear Jerome,
Could you confirm that the proposed solution doesn't cover your case and you ask estimation for the case with parameter "-C".
Thanks.
Could you confirm that the proposed solution doesn't cover your case and you ask estimation for the case with parameter "-C".
Thanks.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: Commenter 1
Date: Wed Oct 20 12:38:16 2021 +0300
0032444: Modeling Algorithm - BRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine
Added checking for null edges in BRepFill_TrimShellCorner::ChooseSection()
[revision removed]
Detailed log of new commits:
Author: Commenter 1
Date: Wed Oct 20 12:38:16 2021 +0300
0032444: Modeling Algorithm - BRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine
Added checking for null edges in BRepFill_TrimShellCorner::ChooseSection()
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: Commenter 1
Date: Wed Oct 20 13:02:09 2021 +0300
0032444: Modeling Algorithm - BRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine
Added checking for null edges in BRepFill_TrimShellCorner::ChooseSection()
[revision removed]
Detailed log of new commits:
Author: Commenter 1
Date: Wed Oct 20 13:02:09 2021 +0300
0032444: Modeling Algorithm - BRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine
Added checking for null edges in BRepFill_TrimShellCorner::ChooseSection()
Dear Participant, we have tested your attached patch. We confirm that it fixes the crash, but the shape is still not valid.
Nevertheless we may integrate it to version 7.6.0 (coming soon) if you have not objections. Confirm it, please.
Anyway, with the ‘-C’ parameter, the problem lies in the intersection of parts of the resulting shape and their trimming.
Most likely, the potential patch #0032447 may fix these bugs. It may be confirmed after patch implementation only.
Nevertheless we may integrate it to version 7.6.0 (coming soon) if you have not objections. Confirm it, please.
Anyway, with the ‘-C’ parameter, the problem lies in the intersection of parts of the resulting shape and their trimming.
Most likely, the potential patch #0032447 may fix these bugs. It may be confirmed after patch implementation only.
Dear Commenter 1, I have no objections, please use my patch if its fix is correct.
Branch [archived branch] has been updated forcibly by Participant.
[revision removed]
[revision removed]
Branch for review:
OCCT - CR32444_1
Results of testing:
http://jenkins-test-occt.nnov.opencascade.com/view/CR32444-master-Commenter 1/view/COMPARE/
OCCT - CR32444_1
Results of testing:
http://jenkins-test-occt.nnov.opencascade.com/view/CR32444-master-Commenter 1/view/COMPARE/
Reviewed.
Branches for integration:
OCCT – CR32444_1
Products – NOT
Branches for integration:
OCCT – CR32444_1
Products – NOT
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: 17728.310000000427 / 17750.15000000046 [-0.12%]
Products
Total CPU difference: 11578.090000000113 / 11624.980000000118 [-0.40%]
Windows-64-VC14:
OCCT
Total CPU difference: 19746.84375 / 19683.796875 [+0.32%]
Products
Total CPU difference: 12740.0 / 10994.3125 [+15.88%]
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: 17728.310000000427 / 17750.15000000046 [-0.12%]
Products
Total CPU difference: 11578.090000000113 / 11624.980000000118 [-0.40%]
Windows-64-VC14:
OCCT
Total CPU difference: 19746.84375 / 19683.796875 [+0.32%]
Products
Total CPU difference: 12740.0 / 10994.3125 [+15.88%]
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]
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records
- #0032445 · related to · closedBRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine
- #0032446 · related to · closedBRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine
- #0031041 · related to · closedModeling Algorithms - Crash in BRepOffsetAPI_MakePipeShell
- #0032588 · has duplicate · closedBRepOffsetAPI_MakePipeShell::Build() crash in BOPDS_DS::Paves (Segmentation fault)