DiscussionsIssue archiveOCCT:Modeling Algorithms

Archived issue #0032444

BRepOffsetAPI_MakePipeShell crash when using -DT mode and DT_ShapeDivide on the spine

CommunityOCCT:Modeling Algorithmsclosed18 public notes

Search issues

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".

Steps to reproduce

test bugs modalg_7 bug32444

Public activity

18 archived notes

Participants are labeled by their role within this record.

01Author
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?
02Author
I added a patch suggestion.
03Commenter 4
Jerome, does your patch with NULL-checks allows to produce expected result, or only protects from the crash?
04Author
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?
05Commenter 1
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))

06Commenter 1
I also attach script to recieve result on Attachment 3 (PNG)
07Author
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?
08Commenter 8
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.
09Commenter 5
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()
10Commenter 5
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()
11Commenter 1
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.
12Author
Dear Commenter 1, I have no objections, please use my patch if its fix is correct.
13Commenter 5
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
14Commenter 1
15Commenter 15
Reviewed.

Branches for integration:
OCCT – CR32444_1
Products – NOT
16Commenter 16
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
17Commenter 5
Branch [archived branch] has been deleted by Participant.

[revision removed]
18Commenter 5
Branch [archived branch] has been deleted by Participant.

[revision removed]

Related records