MantisBT - Community
View Issue Details
0027568Community[OCCT] OCCT:Modeling Algorithmspublic2016-06-03 18:092016-12-09 16:37
Timo 
bugmaster 
normalminor 
closedfixed 
WindowsVC++ 201032 bit
[OCCT] 7.0.0 
[OCCT] 7.1.0[OCCT] 7.1.0 
bugs modalg_6 bug27568
0027568: Exception is thrown when a degenerated edge is added to a wire
Since we updated to OCC 7.0.0, an exception is thrown when a degenerated edge is added to a wire.

Strangely, it occurs only in win32 Release mode, not in Debug and not in win64 mode.

Can you reproduce this behaviour?

The degenerated edge was created in the following way [C#-code]:
            
            BRep_Builder aBuilder = new BRep_Builder();
            TopoDS_Edge e = new TopoDS_Edge();
            aBuilder.MakeEdge(ref e);
            TopoDS_Shape edgeShape = (TopoDS_Shape)e;
            aBuilder.Add(ref edgeShape, p.Oriented(TopAbs_Orientation.TopAbs_FORWARD));
            aBuilder.Add(ref edgeShape, p.Oriented(TopAbs_Orientation.TopAbs_REVERSED));
            aBuilder.Degenerated(e, true);
            aBuilder.UpdateEdge(e, Precision.Precision.Confusion());

It worked in OCC 6.9.0. Does it have to be created in a different way in OCC 7.0.0?
restore curves.brep c

explode c

wire w c_1 c_2
No tags attached.
related to 0025856new msv BRepOffsetAPI_ThruSections returns an invalid shape if one wire contains degenerated edges 
? curves.brep (4,758) 2016-06-03 18:09
https://tracker.dev.opencascade.org/
Issue History
2016-06-03 18:09TimoNew Issue
2016-06-03 18:09TimoAssigned To => msv
2016-06-03 18:09TimoFile Added: curves.brep
2016-06-09 18:06msvNote Added: 0054859
2016-06-09 18:07msvAssigned Tomsv => Timo
2016-06-09 18:07msvStatusnew => feedback
2016-06-13 14:07TimoNote Added: 0054932
2016-06-13 14:08TimoAssigned ToTimo => msv
2016-06-13 14:08TimoNote Edited: 0054932bug_revision_view_page.php?bugnote_id=54932#r13902
2016-06-13 14:25TimoRelationship addedrelated to 0025856
2016-06-14 12:22TimoNote Added: 0054941
2016-06-14 12:25TimoNote Edited: 0054941bug_revision_view_page.php?bugnote_id=54941#r13913
2016-06-14 17:08TimoNote Edited: 0054941bug_revision_view_page.php?bugnote_id=54941#r13918
2016-06-15 17:36gitNote Added: 0055039
2016-06-15 17:37TimoNote Added: 0055040
2016-06-15 17:37TimoStatusfeedback => resolved
2016-06-15 18:03abvNote Added: 0055043
2016-06-15 18:03abvAssigned Tomsv => bugmaster
2016-06-15 18:03abvStatusresolved => reviewed
2016-06-15 19:41mkvAssigned Tobugmaster => mkv
2016-06-15 23:02msvNote Added: 0055049
2016-06-16 13:00mkvNote Added: 0055069
2016-06-16 13:00gitNote Added: 0055070
2016-06-16 13:01mkvAssigned Tomkv => msv
2016-06-16 13:01mkvStatusreviewed => feedback
2016-06-16 13:01mkvTest case number => bugs modalg_6 bug27568
2016-06-16 22:30gitNote Added: 0055113
2016-06-16 22:35abvNote Added: 0055114
2016-06-16 22:35abvAssigned Tomsv => bugmaster
2016-06-16 22:35abvStatusfeedback => reviewed
2016-06-17 13:14apvAssigned Tobugmaster => mkv
2016-06-17 15:12gitNote Added: 0055182
2016-06-20 12:10mkvNote Added: 0055215
2016-06-20 12:10mkvNote Added: 0055216
2016-06-20 12:11mkvNote Added: 0055217
2016-06-20 12:11mkvAssigned Tomkv => bugmaster
2016-06-20 12:11mkvStatusreviewed => tested
2016-06-24 12:41bugmasterChangeset attached => occt master 36723716
2016-06-24 12:41bugmasterStatustested => verified
2016-06-24 12:41bugmasterResolutionopen => fixed
2016-06-24 12:58gitNote Added: 0055426
2016-12-09 16:31aivStatusverified => closed
2016-12-09 16:37aivFixed in Version => 7.1.0

Notes
(0054859)
msv   
2016-06-09 18:06   
I cannot reproduce the problem. What kind of exception you obtained?
By the way, I see incorrect construction of a degenerated edge. A degenerated edge has no any sense without a 2d curve on surface. In order to have a correct edge it has to have a curve on surface representation.
(0054932)
Timo   
2016-06-13 14:07   
(edited on: 2016-06-13 14:08)
Thanks for checking.
After I restarted my computer today, I also cannot reproduce the problem anymore.

Regarding "senseless" degenerated edges without 2d curve on surface, I see some places in OCCT, where such edges are created as an intermediate step, e.g.

- BRepFill_Section::BRepFill_Section(const TopoDS_Shape& Profile,
                   const TopoDS_Vertex& V,
                   const Standard_Boolean WithContact,
                   const Standard_Boolean WithCorrection)

- NullEdge(TopoDS_Shape& Vertex) in BRepFill_Sweep

- BRepProj_Projection::BRepProj_Projection (const TopoDS_Shape& Wire,
                                          const TopoDS_Shape& Shape,
                                          const gp_Pnt& P)

In our code, wires that can contain degenerated edges are given to BRepOffsetAPI_ThruSections, in order to create a shell. Basically, it works well. I don't know why it didn't work last week. Should I better create an "artifical" surface, e.g. a plane, so that the degnerated edge has a 2d curve on surface?

(0054941)
Timo   
2016-06-14 12:22   
(edited on: 2016-06-14 17:08)
Today, after restarting my computer, I was again able to reproduce the problem, but only in win32, release mode. I'm using VS 2010 Professional and Win 10.

The error message in Draw is:
An exception was caught 034A9340 : Standard_DomainError: BRep_Builder::Infinite parameter
** Exception ** 034A9340 : Standard_DomainError: BRep_Builder::Infinite parameter

The exception is thrown by BRep_Builder::UpdateVertex(const TopoDS_Vertex& V,
                                 const Standard_Real Par,
                                 const TopoDS_Edge& E,
                                 const Standard_Real Tol)

In debug mode, Par is -9.2559631349317831e+061 and Precision::IsNegativeInfinite(Par) returns 0. Probably, in release mode Par is different so that Precision::IsNegativeInfinite(Par) returns 1.

After looking into the code, it seems the root cause of this value of Par is an uninitialized variable in BRep_Tool::Parameter(const TopoDS_Vertex& V, const TopoDS_Edge& E), which defines:

  Standard_Real f,l;

and then calls:

  BRep_Tool::Range(E,f,l);

The Range function then iterates over all curve representations to calculate the parameter value. In our case (degenerated curve without curve on surface) there are no representations. So, f and l remain uninitialized.

It seems that the uninitialized variables may have different values under certain circumstances. Wouldn't it be better to initialize these variables in the Range function to some value if there is no curve representation at all?

Or should I better create an "artificial" curve on surface?

(0055039)
git   
2016-06-15 17:36   
Branch CR27568 has been created by Timo.

SHA-1: 611986141b10cccf131a954e74b41d82f5319db6


Detailed log of new commits:

Author: Timo Roth
Date: Wed Jun 15 10:04:44 2016 +0200

    0027568: Exception is thrown when a degenerated edge is added to a wire
(0055040)
Timo   
2016-06-15 17:37   
I pushed a fix which initializes the variables in the Range function. It resolves the issue. What do you think about it?
(0055043)
abv   
2016-06-15 18:03   
Reviewed without remarks, please test
(0055049)
msv   
2016-06-15 23:02   
I would add the same protection in another function (located the next after the corrected one):

void BRep_Tool::Range(const TopoDS_Edge& E,
                       const Handle(Geom_Surface)& S,
                       const TopLoc_Location& L,
                       Standard_Real& First,
                       Standard_Real& Last)
(0055069)
mkv   
2016-06-16 13:00   
Dear BugMaster,
Branch CR27568 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
SHA-1: 611986141b10cccf131a954e74b41d82f5319db6

Number of compiler warnings:

occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)

products component :
Linux: 72 (72 on master)
Windows: 4 (4 on master)
MacOS : 1136

Regressions/Differences/Improvements:
No regressions/differences

Testing cases:
http://occt-tests/CR27568-master-OCCT/Debian70-64/bugs/modalg_6/bug27568.html [^]
http://occt-tests/CR27568-master-OCCT/Windows-64-VC10/bugs/modalg_6/bug27568.html [^]
bugs modalg_6 bug27568: OK

Testing on Linux:
occt component :
Total MEMORY difference: 88450459 / 88287115 [+0.19%]
Total CPU difference: 19452.099999999995 / 19440.449999999968 [+0.06%]
products component :
Total MEMORY difference: 27639521 / 27632321 [+0.03%]
Total CPU difference: 5177.729999999983 / 5150.779999999989 [+0.52%]

Testing on Windows:
occt component :
Total MEMORY difference: 55964750 / 55988768 [-0.04%]
Total CPU difference: 18293.426064798892 / 19083.36832849891 [-4.14%]
products component :
Total MEMORY difference: 18749023 / 18714258 [+0.19%]
Total CPU difference: 4999.348446899955 / 5090.484231099957 [-1.79%]

There are no differences in images found by testdiff.
(0055070)
git   
2016-06-16 13:00   
Branch CR27568 has been updated by mkv.

SHA-1: de5a7b2e769ea7511b44d83feece17eda23ea7da


Detailed log of new commits:

Author: mkv
Date: Thu Jun 16 12:02:50 2016 +0300

    Test cases for issue CR27568

(0055113)
git   
2016-06-16 22:30   
Branch CR27568 has been updated by abv.

SHA-1: c33025c2177e9d9edf790a547c8a5db9c681b612


Detailed log of new commits:

Author: abv
Date: Thu Jun 16 22:29:49 2016 +0300

    Other methods of BRep_Tool corrected to ensure that output arguments are always initialized

(0055114)
abv   
2016-06-16 22:35   
The test is useless as it does not generate failure without the fix. To make it useful, we need to run it under Valgrind or similar memory-checking tool.

Besides, I have added initialization of output arguments in other methods of BRep_Tool, please re-test. I did not change second method Range() since it should have both output arguments initialized in all control paths, provided that the methods Range() it calls do that.
(0055182)
git   
2016-06-17 15:12   
Branch CR27568 has been updated forcibly by mkv.

SHA-1: 16ebcecc212a1572e4ddb8e651eec93901431515
(0055215)
mkv   
2016-06-20 12:10   
Dear BugMaster,
Branch CR27568 was rebased on current master of occt git-repository.
SHA-1: 16ebcecc212a1572e4ddb8e651eec93901431515
(0055216)
mkv   
2016-06-20 12:10   
Dear BugMaster,
Branch CR27568 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested on Release mode.
SHA-1: 16ebcecc212a1572e4ddb8e651eec93901431515

Number of compiler warnings:

occt component :
Linux: 0 (0 on master)
Windows: 0 (0 on master)
MacOS : 0 (0 on master)

products component :
Linux: 68 (68 on master)
Windows: 0 (0 on master)
MacOS : 1129

Regressions/Differences/Improvements:
No regressions/differences

Testing cases:
http://occt-tests/CR27568-master-OCCT/Debian70-64/bugs/modalg_6/bug27568.html [^]
http://occt-tests/CR27568-master-OCCT/Windows-64-VC10/bugs/modalg_6/bug27568.html [^]
bugs modalg_6 bug27568: OK

Testing on Linux:
occt component :
Total MEMORY difference: 87725743 / 89175825 [-1.63%]
Total CPU difference: 19423.329999999896 / 19458.61999999997 [-0.18%]
products component :
Total MEMORY difference: 27486404 / 27412842 [+0.27%]
Total CPU difference: 5173.25999999998 / 5165.429999999985 [+0.15%]

Testing on Windows:
occt component :
Total MEMORY difference: 55896161 / 55902235 [-0.01%]
Total CPU difference: 18333.87712409896 / 18535.586417098955 [-1.09%]
products component :
Total MEMORY difference: 18649378 / 18614185 [+0.19%]
Total CPU difference: 5023.7626033999495 / 4998.802443399952 [+0.50%]

There are no differences in images found by testdiff.
(0055217)
mkv   
2016-06-20 12:11   
Dear BugMaster,
Branch CR27568 is TESTED.
(0055426)
git   
2016-06-24 12:58   
Branch CR27568 has been deleted by inv.

SHA-1: 16ebcecc212a1572e4ddb8e651eec93901431515