MantisBT - Community
View Issue Details
0026308Community[OCCT] OCCT:Modeling Algorithmspublic2015-06-03 14:322019-08-24 09:51
LinuxDebian 6.032 bit
[OCCT] 6.7.1 
[OCCT] 6.9.1[OCCT] 6.9.1 
bugs modalg_6 bug26308
0026308: Segmentation fault in BSplCLib::LocateParameter
I am solving differential equations on Geom_Surfaces made out of TopoDS_Faces. The solver may perform computations on the surface at coordinates that are far outside the surface boundary. As the solution converges, the evaluations happen closer to the actual surface and finally they are withing the surface boundary. It is therefore great for me, that the methods D0, D1 and D2 of Geom_Surface may be used with arbitrary parameters, not only with parameters within certain bounds.

But when using extreme u and v parameters passed to D0 or D2, severe errors may happen. In the method BSplCLib::LocateParameter (from line 220 to 283 in the file BSplCLib.cxx of my community edition version) the boundaries of the array "knots" are exceeded in the line 278:

K2 = knots[KnotIndex + 1];

On Windows I have sporadic crashes. On Linux when using Valgrind, it displays an invalid read of size 8 in this line. When I debug this line, I find situations where KnotIndex + 1 is 13, but Last is 12 and Last1 is 11. Therefore I have concluded that the array boundaries are exceeded.

If my presumption was right, an easy solution could be to throw a Standard_OutOfRange failure in such a case. Then the caller could react. This happens to me only when the u and v parameters have extremely large absolute values. Therefore throwing a failure would already help to recognize such cases. Only crashes are extremely bad for me!
ReadStep D_First Face.stp
XGetOneShape rr D_First
explode rr f
mksurface ss rr_1

svalue ss -1.427997381773311e+018 4.512451574816904e+016 xx yy zz

dump xx yy zz

*********** Dump of xx *************

*********** Dump of yy *************

*********** Dump of zz *************
lead to the described Valgrind error and debugging situation as described above on my Linux 32 machine. The crashes on Windows 64 are sporadic, therefore I cannot give definite information about that, but when a crash appeared it was close to such a call to D0 with extreme u and v values.
No tags attached.
related to 0030875closed abv Community Foundation Classes - BSplCLib crashes in case of infinite upper knot 
? Face.stp (21,314) 2015-06-03 14:32
Issue History
2015-06-03 14:32BenjaminBihlerNew Issue
2015-06-03 14:32BenjaminBihlerAssigned To => msv
2015-06-03 14:32BenjaminBihlerFile Added: Face.stp
2015-06-03 16:53msvAssigned Tomsv => ifv
2015-06-23 10:55ifvAssigned Toifv => nbv
2015-06-23 10:55ifvStatusnew => assigned
2015-06-23 11:09nbvRelationship addedrelated to 0026281
2015-07-09 14:40gitNote Added: 0042861
2015-07-09 14:41nbvNote Added: 0042862
2015-07-09 14:46nbvNote Added: 0042864
2015-07-09 14:46nbvAssigned Tonbv => msv
2015-07-09 14:46nbvStatusassigned => resolved
2015-07-09 14:46nbvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=10915#r10915
2015-07-09 14:46nbvAdditional Information Updatedbug_revision_view_page.php?rev_id=10917#r10917
2015-07-09 14:48nbvSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=10918#r10918
2015-07-09 14:53BenjaminBihlerNote Added: 0042866
2015-07-09 15:15msvNote Added: 0042868
2015-07-09 15:15msvAssigned Tomsv => bugmaster
2015-07-09 15:15msvStatusresolved => reviewed
2015-07-09 17:59apvAssigned Tobugmaster => apv
2015-07-09 18:09gitNote Added: 0042887
2015-07-09 18:09apvNote Added: 0042888
2015-07-10 15:33apvNote Added: 0042919
2015-07-10 15:33apvAssigned Toapv => nbv
2015-07-10 15:33apvStatusreviewed => assigned
2015-07-10 15:33apvNote Edited: 0042919bug_revision_view_page.php?bugnote_id=42919#r10938
2015-07-13 14:09nbvNote Added: 0042958
2015-07-13 14:10nbvNote Added: 0042959
2015-07-13 14:10nbvAssigned Tonbv => msv
2015-07-13 14:10nbvStatusassigned => resolved
2015-07-13 15:03msvNote Added: 0042964
2015-07-13 15:03msvAssigned Tomsv => bugmaster
2015-07-13 15:03msvStatusresolved => reviewed
2015-07-13 15:28nbvNote Added: 0042968
2015-07-13 17:04apvAssigned Tobugmaster => apv
2015-07-13 17:04apvStatusreviewed => feedback
2015-07-13 18:19apvNote Added: 0042980
2015-07-13 18:45gitNote Added: 0042981
2015-07-15 09:40apvNote Added: 0043031
2015-07-15 09:40apvAssigned Toapv => bugmaster
2015-07-15 09:40apvStatusfeedback => tested
2015-07-15 09:47apvTest case number => bugs modalg_6 bug26308
2015-07-15 11:10nbvAssigned Tobugmaster => nbv
2015-07-15 11:10nbvStatustested => feedback
2015-07-15 11:15gitNote Added: 0043042
2015-07-15 11:17nbvNote Added: 0043043
2015-07-15 11:17nbvAssigned Tonbv => apv
2015-07-15 11:52apvAssigned Toapv => bugmaster
2015-07-15 11:52apvStatusfeedback => tested
2015-07-23 11:55bugmasterChangeset attached => occt master fd03c080
2015-07-23 11:55bugmasterStatustested => verified
2015-07-23 11:55bugmasterResolutionopen => fixed
2015-07-23 13:25bugmasterTarget Version => 7.0.0
2015-08-14 10:56gitNote Added: 0044190
2015-08-26 11:08abvTarget Version7.0.0 => 6.9.1
2015-10-16 14:56aivStatusverified => closed
2015-10-23 20:50aivFixed in Version => 6.9.1
2019-08-24 09:51abvRelationship addedrelated to 0030875

2015-07-09 14:40   
Branch CR26308 has been created by nbv.

SHA-1: 867cdc7799a385bc7f1f887db1961501db581f4a

Detailed log of new commits:

Author: nbv
Date: Fri Jul 3 15:31:53 2015 +0300

    0026308: Segmentation fault in BSplCLib::LocateParameter
    Detection of "jumping" knot value has been improved.
2015-07-09 14:41   
Dear BenjaminBihler,

First of all, I would like to draw your attention to the fact that according to the spline theory, every B-spline curve/surface is defined ONLY in the range set by its knot sequence t. It associated with the formula for computing B-spline basis ( [^]):

B[i,1] (x) = (t[i] <= x) && (x < t[i+1]) ? 1 : 0

Consequently, if the parameter is outside the curve/surface boundaries then all bases are equal to zero. Therefore, curve/surface value IS EQUAL TO ZERO, too.
Nevertheless, there is a possibility to expand B-spline curve/surface. If you are interested in this question, you will be able to read, [^] page 114. Prepared code (for FORTRAN compiler) you can find here: [^]

However, it is a bad idea to compute value for outside parameter, especially if its value is too far from domain boundary. E.g. value of attached by you surface has coordinates ~ 1.0e+207. This is a bad number because you will not been able to compute even its square (e.g. in order to find the distance from this point to origin). This fact you must check in your code.
2015-07-09 14:46   
Dear Mikhail,

Please review CR26308 branch.
2015-07-09 14:53   
Dear nbv,

thank you very much for your answer. You are totally right that very large doubles cannot lead to reasonable results.

I have implemented a pre-check that will prevent evaluation, if any of the coordinates is larger than 1.0e10. But it might still be desireable to do computations with quite large numbers (as explained in the bug report). Therefore I am happy that you have cared for the crash.

Thank you,
2015-07-09 15:15   
2015-07-09 18:09   
Branch CR26308 has been updated forcibly by apv.

SHA-1: c723e65e0446af1cc85b318fa10000d10759669d
2015-07-09 18:09   
Branch CR26308 has been rebased on the IR-2015-07-09
2015-07-10 15:33   
Dear BugMaster,

Branch CR26308 from occt git-repository (and master from products git-repository) was compiled on Linux and Windows platforms and tested.
SHA-1: c723e65e0446af1cc85b318fa10000d10759669d

Number of compiler warnings:
occt component:
   Linux: 24 (24 on master)
   Windows: 0 (0 on master)
products component:
   Linux: 37 (37 on master)
   Windows: 0 (0 on master)

http://occt-tests/CR26308-IR-2015-07-09-products-64/Debian70-64/summary.html [^]
http://occt-tests/CR26308-IR-2015-07-09-products-64/Windows-64-VC10/summary.html [^]
emesh bugs bug26326_2
sat doc_1 Y4
sat doc_6 A5

2015-07-13 14:09   
sat doc_1 Y4
This is an IMPROVEMENT because on MASTER we have two differences with reference data. On CR26308, one difference has been vanished.

  sat doc_6 A5
Current state (on CR26308) is as same as before fixing bug 0024682. I think, it is valid result.

  emesh bugs bug26326_2
The shape is a priory BAD because it contains an edge with following 2D-curve (bent is evidend):

Dump of 2 Curve2ds

   1 : BSplineCurve
  Degree 11, 403 Poles, 41 KnotsPoles :
... (Poles)
  370 : 2.99310967351215e+022, 5.95716002980578e+022
  371 : -2.244175163394e+022, -4.46656221840557e+022
  372 : 1.38391514324393e+022, 2.75439421713599e+022
  373 : -2.75483061094339e+022, -5.48291529362524e+022
  374 : 1.61472928236001e+023, 3.21378158139615e+023
  375 : -4.67523800309315e+023, -9.30508534596214e+023

There is no point in expecting some good result on this shape.


Regression tests should be changed in accordance with their new behavior.
2015-07-13 14:10   
Dear Mikhail,

Please confirm above said.
2015-07-13 15:03   
2015-07-13 15:28   
Dear testers.

Please increase relative error for area computing to 10% in emesh bugs bug26326_2 test case. After that the test will be OK.
2015-07-13 18:19   
Branch CR26308 has been created in products git-repository
2015-07-13 18:45   
Branch CR26308 has been updated by apv.

SHA-1: a3e49a054cd40d9c7b1b4dbfacd0003cb841661b

Detailed log of new commits:

Author: apv
Date: Mon Jul 13 18:45:08 2015 +0300

    Test-case for issue 0026308

2015-07-15 09:40   
Dear BugMaster,

Branch CR26308 from occt git-repository (and master from products git-repository) was compiled on Linux and Windows platforms and tested.
SHA-1: c723e65e0446af1cc85b318fa10000d10759669d

Number of compiler warnings:
occt component:
   Linux: 24 (24 on master)
   Windows: 0 (0 on master)
products component:
   Linux: 37 (37 on master)
   Windows: 0 (0 on master)

Not detected

Testing cases:
bugs modalg_6 bug26308 - OK
http://occt-tests/CR26308-IR-2015-07-09-occt-64/Debian70-64/bugs/modalg_6/bug26308.html [^]
http://occt-tests/CR26308-IR-2015-07-09-occt-64/Windows-64-VC10/bugs/modalg_6/bug26308.html [^]

Testing on Linux:
Total MEMORY difference: 97211350 / 96675793 [+0.55%]
Total CPU difference: 17650.55999999994 / 17382.779999999697 [+1.54%]

Testing on Windows:
Total MEMORY difference: 56564237 / 56518528 [+0.08%]
Total CPU difference: 16080.645480398991 / 15985.266468998929 [+0.60%]

There is difference in images found by testdiff:
http://occt-tests/CR26308-IR-2015-07-09-products-64/Debian70-64/diff-Debian70-64.html [^]
http://occt-tests/CR26308-IR-2015-07-09-products-64/Windows-64-VC10/diff-Windows-64-VC10.html [^]
emesh bugs bug26326_1
2015-07-15 11:15   
Branch CR26308 has been updated by nbv.

SHA-1: 671c6bb2221f465b91d205fd4ea8092e803eb969

Detailed log of new commits:

Author: nbv
Date: Wed Jul 15 11:14:15 2015 +0300

    Comment has been added in test case bugs/modalg_6/bug26308.

2015-07-15 11:17   
Test case bugs modalg_6 bug26308 has been reviewed with insignificant correction.
2015-08-14 10:56   
Branch CR26308 has been deleted by inv.

SHA-1: 671c6bb2221f465b91d205fd4ea8092e803eb969