View Issue Details

IDProjectCategoryView StatusLast Update
0025971CommunityOCCT:Modeling Datapublic2015-06-25 16:08
ReporterRoman Lygin Assigned Tobugmaster  
Status closedResolutionfixed 
Product Version6.8.0 
Target Version6.9.0Fixed in Version6.9.0 
Summary0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
DescriptionA model coming out of Shape Healing has B-Spline pcurve with knots differing in 17th position. After exporting to STEP it cannot be read back as the precision got lost and knots get fully equal and the B-Spline ctor throws an exception in CheckCurveData().

What happens is the following. The original edge lies on an original longer pcurve and has some shorter range [a,b]. b is very close to an existing B-Spline knot. Then GeomLib::SameRange() called inside FixSameParameter() converts a trimmed curve on the original B-Spline and sets a 3D curve range [A,B]. This B-Spline had a knot very near the split point and although the delta is > Epsilon(K(i)), which is checked in CheckCurveData(), after saving to a text file, the double numbers become fully collapsed.

There are different approaches to address this, for instance:
1. Make various adjustments in multiple algorithms (during import/export, ConvertToBSpline, BSplineCurve::Segment(),...)
2. Create an explicit pre-processing function (e.g. in BSplCLib) which would check and adjust knot array by moving them apart by at least Precision::PConfusion(). Such fixes are often made in IGES and STEP importers.
3. Make BSpline ctor less sensitive to merged knots and for instance have it call to the above function. In this case B-Spline ctor itself could be less sensitive to such round-off errors.

A discussion will be open on to solicit opinions on the best course of actions.
Steps To Reproducerestore C:/temp/a_328_1.brep a
fixshape f a 1e-6
explode f e
dump f_4

Knots :
  12 : 6.28318530717959 1
  13 : 6.28318530717959 4

stepwrite a f C:/temp/f.stp #inside the file there are two merged knots 6.28318530718,6.28318530718
stepread C:/temp/f.stp ff #select 1
numsh ff # no faces
tps c #Exception caught for the shell

TagsNo tags attached.
Test case numberbugs moddata_2(013) bug253, bugs moddata_3(014) bug25971

Attached Files

  • (642 bytes)
  • (1,309 bytes)
  • 0002-Make-the-same-patch-for-3d-curve-and-surface.patch (2,309 bytes)


related to 0023175 closeddbv Community Failed to segment a periodic B-Spline when parameter coincides with existing knot 
related to 0022989 closedbugmaster Community BSplCLib::Reparametrize() fails on near knots 


Roman Lygin

2015-03-23 12:20

developer (642 bytes)


2015-03-24 19:26

administrator   ~0038857

Branch CR25971 has been created by Roman Lygin.

SHA-1: 6ec1e6d868b37ad4b56da887ee2807c3a245b52f

Detailed log of new commits:

Author: Roman Lygin
Date: Tue Mar 24 19:25:28 2015 +0400

    0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)

Roman Lygin

2015-03-24 19:31

developer   ~0038858

Conservative fix made which only ensures sufficient delta (Precision::PConfusion()) in BSplCLib::Reparametrize().

The other likely candidate InsertKnots() left unchanged until a first case is encountered.

The fix ensures that new range really gets [U1, U2] as this may be expected by the caller algorithm (e.g. SameRange() or user's). If the delta between the last and last but one knot is less than required threshold, then iterates back trying to adjust the knot reducing their values.

Roman Lygin

2015-03-24 19:32

developer   ~0038859

Another candidate for alignment is ShapeConstruct_Curve::FixKnots().


2015-03-25 15:32

developer   ~0038891



2015-03-30 14:30

tester   ~0038978

Dear BugMaster,

Branch CR25971 from occt git-repository (and master from products git-repository) was compiled on Linux, MacOS and Windows platforms and tested.
SHA-1: 6ec1e6d868b37ad4b56da887ee2807c3a245b52f

Number of compiler warnings:
occt component:
   Linux: 18 (18 on master)
   Windows: 0 (0 on master)
products component:
   Linux: 11 (11 on master)
   Windows: 4 (4 on master)

de iges_1 P5
de step_2 B8, C9, D6, E7
de step_3 D1

Testing on Linux:
Total MEMORY difference: 88265082 / 88458413 [-0.22%]
Total CPU difference: 50133.61000000006 / 53140.31000000024 [-5.66%]

Testing on Windows:
Total MEMORY difference: 50008751 / 50016623 [-0.02%]
Total CPU difference: 14766.446256099613 / 14819.845398399693 [-0.36%]

There is difference in images found by testdiff:
bugs vis bug24717


2015-03-30 17:33

administrator   ~0039000

Branch CR25971 has been updated forcibly by msv.

SHA-1: b46ddd23f10d84485997875a013825fbee5f450d


2015-04-01 10:11

developer   ~0039070

I have analyzed one of regressions, the test de iges_1 P5. With the fix, several handled exceptions occur in the method CheckCurveData. In the result, several edges are not fixed, and the nature of regression itself is different number of vertices in the resulting shape.

I have caught the problematic knots data in the fixed method BSplCLib::Reparametrize. The input array contains 10 items, with the range [0.67018055240076602,0.70588240000000002]. The requested range is U1=0.70588239799999997, U2=0.70588240000000002. We can see that the new length is equal to 2e-9. There is no room in the range to place 10 knots having distance between them greater than 1e-9. As the result, the procedure ruins the knots sequence, violating ascending order, and this later leads to exception in CheckCurveData.

One possible solution would be to restrict movement of knots after scaling, limiting shift value so that after shifting the ratio between neighboring intervals did not changed significantly. This would preserve the form of the knots sequence and even more so avoid distortion of ascending order.

However, after discussion with ABV, we came to conclusion that the overall fix could be made in another way. If the coinciding knots are created during splitting in the Segment method, it might be better to treat such cases in that code, rather than let Reparametrize distort the knots form on regular base.

Dear Roman, please let me know if you are willing to continue the fix. If so I shall send you private shape data needed to perform the regressed test.


2015-04-01 10:19

manager   ~0039072

One more point is: if Segment() is called with arguments leading to creation of very small interval (<1e-9), I believe it is better to eliminate this interval instead of trying to increase it to 1e-9. This way we can avoid creation of small parametric intervals which are possible source of problems anyway.


2015-04-01 10:30

developer   ~0039074

One more point. It would be very nice to prepare a test case that was a starting point to this issue. I mean a draw script with possible shape (or better shape generated on the fly) that reproduce problem of not enough precision of import/export through a file.
Roman, I shall be very pleased if you could prepare a test case.

Roman Lygin

2015-04-07 15:08

developer   ~0039310

Hi Mikhail,
Thank you for your triaging. The very start point was a customer file which I obviously cannot disclose. Anyway, the synthetic reproducer was already provided in the report and is an excerpt of one of the subshapes with similar issues. Please let me know if there is anything you might need further details on.
My efforts on fixing have been deferred and unless you want to take ownership of this bug and continue on your own, please do send me the private data, so that I or my team could resume at any moment.


2015-04-08 18:06

administrator   ~0039381

Branch CR25971 has been updated forcibly by msv.

SHA-1: 35dd50465f24604f938c5cc074a6b4b19f9e5e6d


2015-04-08 18:11

developer   ~0039382

Last edited: 2015-04-08 18:13

I have re-based the branch CR25971 on current master and put there the newly added test case "bugs fclasses bug25971" based on the steps to reproduce.
The test case is classified as "Bad" on master and as "Improvement" on the branch.
"Todo" lines are to be removed from the script when the solution is ready to be integrated.


2015-04-17 10:29

administrator   ~0039943

Branch CR25971_1 has been created by Roman Lygin.

SHA-1: 43ebf89c220b4bbbabdf78ccb907f3b0b594e789

No new revisions were added by this update.

Roman Lygin

2015-04-17 11:13

developer   ~0039944

Mikhail, Andrey,

A new version of the fix (possibly interim) has been pushed as CR25971_1 branch.
The status has not been upgraded to resolved yet, as I would like to try a better fix even if the current one seems to work fine.
Below are some comments:

1. I've followed your recommendation to address the issue upstream in Segment(). There was already a code that tried to stick the split point to existing knot if the distance was within epsilon. Now this epsilon was increased to at least Precision::PConfusion().

2. The fix works fine: no regression on public data and on the IGES case de iges_1 P5.
The STEP cases (
de step_3 D1
de step_2 B8, C9, D6, E7)

now contain the following differences:

(example of de step_3 D1)
Error : 3 differences with reference data found :
 Reference data - NBSHAPES : Solid = 0 ( 0 ) Shell = 95 ( 106 ) Face = 95 ( 106 ) Summary = 1451 ( 1665 )
 Current data - NBSHAPES : Solid = 0 ( 0 ) Shell = 106 ( 106 ) Face = 106 ( 106 ) Summary = 1665 ( 1665 )

Investigation reveals that prior to the fix there were lost entities (e.g. 11 faces, 95 vs 106) due to exact same error which the bug report 25971 is about - during loopback test, the near knots were saved in a STEP file as equal values and reading back led to exceptions (CheckCurveData() and lost entities).
Now the fix addresses this, B-Splines are different and STEP files are stored differently and can be read back.
Thus, this is an improvement, not a regression and the reference data needs to be updated.

3. The fix is currently applied to Geom2d_BSplineCurve::Segment(). Natural intent would be to apply it likewise to Geom_BSplineCurve::Segment(), however apparently these codes diverged significantly in the past. So an attempt to
synchronize them may likely lead to regressions as this is too sensitive code. Ideally, most B-Spline methods implementations should be template-based and just compile for 2D/3D cases but obviously this is a good effort in its own, and is beyond this bug report. So my course of actions will be:
- try to have a synchronized code
- run regressions tests on public data
- if fails, rollback back to current fix and just insert comments that this 2D-only fix was a deliberate choice
- if succeeds, the fix will be pushed to the repository so that you can cover the entire test suite
- if fails, rollback
- if succeeds, you integrate the entire fix.

Does that sound OK with you ?

Thank you,

Roman Lygin

2015-04-17 11:19

developer   ~0039945

For the sake of better clarity, let me add some further details on the original issue:

1. Knots of original 2D B-Spline curve:
    [1] -1.5707963267949001 double
    [2] -1.4279966607226364 double
    [10] -0.28559933214452715 double
    [11] -0.14279966607226346 double
    [12] 2.2204460492503131e-016 double
    [13] 0.14279966607226369 double
    [23] 1.5707963267949001 double
2. Edge range on this p-curve:
[-1.5707963267949001, 1.3322676295501878e-015]

Eps(k12) = 2.2204460492503131e-016 < |1.3322676295501878e-015 - 2.2204460492503131e-016|

3. Segment() is called with (-1.5707963267949001, 1.3322676295501878e-015) and creates:

    [1] -1.5707963267949001 double
    [11] -0.14279966607226346 double
    [12] 2.2204460492503131e-016 double
    [13] 1.3322676295501878e-015 double

4. Reparametrize() is called with (4.7123889803846861, 6.2831853071795880) and creates:
new 12 = 6.2831853071795871
new 13 = 6.2831853071795880
Eps (new 12) = 8.8817841970012523e-016, also < | 6.2831853071795880 - 6.2831853071795871|

5. Saving to text format collapses new knots 12 and 13:

6. Restoring throws an exception.


2015-04-17 14:54

developer   ~0039956

Roman, sorry but I have not found the new branch in the repository.


2015-04-17 15:05

developer   ~0039957

Concerning the plan of actions described in the note 0025971:0039944, it is good.
And thank you for the note 0025971:0039945, it just confirms our hypothesis.


2015-04-17 15:24

administrator   ~0039958

Branch CR25971_2 has been created by Roman Lygin.

SHA-1: 43ebf89c220b4bbbabdf78ccb907f3b0b594e789

No new revisions were added by this update.


2015-04-17 15:32

administrator   ~0039962

Branch CR25971_1 has been updated by Roman Lygin.

SHA-1: 7d1c80335fc067aac43fb2b6200f4e0b81789654

Detailed log of new commits:

Author: Roman Lygin
Date: Fri Apr 17 15:31:32 2015 +0400

    0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)

Roman Lygin

2015-04-17 16:15

developer   ~0039970

Unfortunately the attempt to align implementations did not work out - regressions showed up even after an attempt to redesign the 2D case (see enclosed excerpt for Geom2d_BSplineCurve::Segment()). Using the same code for 3D case produced even greater number of regressions.

So the only feasible action at this moment could be to accept the prior fix (in CR25971_1 branch). And at some point in time to allocate a project to align implementations of 2D/3D curve and Geom_BSplineSurface() investigating regressions.

Roman Lygin

2015-04-17 16:16

developer (1,309 bytes)


2015-04-17 18:45

developer   ~0039998

Last edited: 2015-04-17 18:46

Dear Roman,
I did not understand the nature of your trials in 3D case. Did you tried just the same patch as for 2D? Like the below patch:

diff --git a/src/Geom/Geom_BSplineCurve.cxx b/src/Geom/Geom_BSplineCurve.cxx
index 01a3a06..2c9de2a 100644
--- a/src/Geom/Geom_BSplineCurve.cxx
+++ b/src/Geom/Geom_BSplineCurve.cxx
@@ -35,6 +35,7 @@
 #include <BSplCLib.hxx>
 #include <BSplCLib_KnotDistribution.hxx>
 #include <BSplCLib_MultDistribution.hxx>
+#include <Precision.hxx>
 #include <Standard_NotImplemented.hxx>
 #include <Standard_ConstructionError.hxx>
 #include <Standard_OutOfRange.hxx>
@@ -570,7 +571,7 @@ void Geom_BSplineCurve::Segment(const Standard_Real U1,
   AbsUMax = Max(AbsUMax, Max(Abs(FirstParameter()),Abs(LastParameter())));
 // Modified by Sergey KHROMOV - Fri Apr 11 12:15:40 2003 End
- Standard_Real Eps = 100. * Epsilon(AbsUMax);
+ Standard_Real Eps = Max (Epsilon(AbsUMax), Precision::PConfusion());
   InsertKnots( Knots, Mults, Eps);
If not, then I would propose to insert this fix to the branch for testing.


2015-04-17 18:53

developer   ~0039999

Also, the similar simple change can be done in surface methods:


2015-04-18 16:08

administrator   ~0040024

Branch CR25971_2 has been updated by abv.

SHA-1: 6b840be0620a63b35924454e6031be9be5e06860

Detailed log of new commits:

Author: Roman Lygin
Date: Fri Apr 17 15:31:32 2015 +0400

    0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
    Precision used to consider B-Spline knots identical is restricted to be not less than Precision::PConfusion() in Geom2d_BSplineCurve::Segment().
    Affected tests updated (improvements)


2015-04-18 18:12

manager   ~0040025

I have pushed the fix rebased on current master and with corrected test cases to branch CR25971_2


2015-04-18 18:13

manager   ~0040026

Reviewed, please test

Roman Lygin

2015-04-20 13:15

developer   ~0040044

Hello Mikhail, Andrey,

Thank you for your support in moving this forward.
I ran out of cycles and won't have any free ones to continue with this any time soon :-(.

Just for the record, here is what was my course of actions:
1. Tried the 2D-only fix as in the branch CR25971_1 on public and private set - OK.
2. Tried to have a better 2D case - the one which was attached to this bug report - fail.
   The need for this reworked/simplified patch is that current code in Geom2d_BSplineCurve::Segment()
      is prone to issues - the loop analyzing the distance between existing knots and parameters and
      comparing with aEps may choose a wrong far distant knot. For instance:
      ki-1, ki, ki+1, ki+2 - all distances < 1e-9
      insert U in [ki-1,ki]
      the loop will stick U to ki+2, not to ki-1.
      Therefore an attempt was to first find an interval for U (via LocateParameter() which itself should
      simply call BSplCLib::Hunt() and adjust to ki if U=ki) and then stick to left or right.
3. 0000002 adjusted for Geom_BSplineCurve::Segment() - fail
4. Geom_BSplineSurface::Segment() was in the middle of refactoring (trying to use logic of 0000002) when
   all those regressions started to show up.
So in general this rather seems as a significant dedicated effort to align implementations and to
enforce maximum possible code reuse instead of duplication and divergence. You might want to fork
a dedicated feature request as a follow up of this bug report.

Looking forward to getting the complete test run results.


2015-04-21 15:18

developer   ~0040074

If we decide to make the same patch for 3d curve and surface, the following info can be useful.
I have run all tests and got the following 3 regressions:

CASE boolean bcut_complex N6: FAILED (bad shape)
CASE boolean bopfuse_complex E5: FAILED (bad shape)
CASE bugs modalg_5 bug24746: FAILED (error)


2015-04-21 15:19


0002-Make-the-same-patch-for-3d-curve-and-surface.patch (2,309 bytes)


2015-04-21 15:20

developer   ~0040075

I have uploaded the patch mentioned above as the file 0002-Make-the-same-patch-for-3d-curve-and-surface.patch.


2015-04-23 19:07

tester   ~0040180

Dear BugMaster,
Branch CR25971_2 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: 6b840be0620a63b35924454e6031be9be5e06860

Number of compiler warnings:

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

products component :
Linux: 4 (4 on master)
Windows: 0 (0 on master)

No regressions/differences

Testing cases:
bugs moddata_3(014) bug25971: OK

Testing on Linux:
occt component :
Total MEMORY difference: 95185562 / 94542797 [+0.68%]
Total CPU difference: 53319.87999999919 / 52220.829999999456 [+2.10%]
products component :
Total MEMORY difference: 23733009 / 23676267 [+0.24%]
Total CPU difference: 17536.789999999975 / 17777.469999999976 [-1.35%]

Testing on Windows:
occt component :
Total MEMORY difference: 57139226 / 57149644 [-0.02%]
Total CPU difference: 15989.244494498982 / 16281.184765899072 [-1.79%]
products component :
Total MEMORY difference: 15561089 / 15564896 [-0.02%]
Total CPU difference: 6400.034625599986 / 6585.207812599981 [-2.81%]

There are following differences in images found by testdiff.
IMAGE de step_2 C9: C9.png differs
IMAGE de step_3 D1: D1.png differs


2015-04-23 19:07

administrator   ~0040181

Branch CR25971_2 has been updated by mkv.

SHA-1: ff612506d8081ac39d7c836ae37c7db38f0f025a

Detailed log of new commits:

Author: mkv
Date: Thu Apr 23 19:07:00 2015 +0300

    Test case for issue CR25971


2015-04-23 19:08

tester   ~0040182

Dear msv,
could you please review following test case
bugs moddata_3(014) bug25971

This test case is OK on current master also.


2015-04-24 11:58

developer   ~0040199

Test case is OK. Really, in current master the test is OK also. It might be due to some recent changes.
Anyway, please integrate this test as it is.


2015-04-28 20:52

tester   ~0040390

Dear BugMaster,
Branch CR25971_2 is TESTED.


2015-05-14 16:32

administrator   ~0041037

Branch CR25971 has been deleted by inv.

SHA-1: 35dd50465f24604f938c5cc074a6b4b19f9e5e6d


2015-05-14 16:32

administrator   ~0041038

Branch CR25971_1 has been deleted by inv.

SHA-1: 7d1c80335fc067aac43fb2b6200f4e0b81789654


2015-05-14 16:32

administrator   ~0041039

Branch CR25971_2 has been deleted by inv.

SHA-1: ff612506d8081ac39d7c836ae37c7db38f0f025a

Related Changesets

occt: master 7b1c1b7c

2015-04-30 11:17:13

Roman Lygin

Committer: bugmaster Details Diff
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)

Precision used to consider B-Spline knots identical is restricted to be not less than Precision::PConfusion() in Geom2d_BSplineCurve::Segment().

Affected tests updated (improvements)

Test case for issue CR25971
Affected Issues
mod - src/Geom2d/Geom2d_BSplineCurve.cxx Diff File
mod - tests/bugs/moddata_2/bug253 Diff File
add - tests/bugs/moddata_3/bug25971 Diff File
mod - tests/de/step_2/B8 Diff File
mod - tests/de/step_2/C9 Diff File
mod - tests/de/step_2/D6 Diff File
mod - tests/de/step_2/E7 Diff File
mod - tests/de/step_3/D1 Diff File

Issue History

Date Modified Username Field Change
2015-03-23 12:20 Roman Lygin New Issue
2015-03-23 12:20 Roman Lygin Assigned To => msv
2015-03-23 12:20 Roman Lygin File Added:
2015-03-24 17:08 Roman Lygin Relationship added related to 0023175
2015-03-24 17:11 Roman Lygin Relationship added related to 0022989
2015-03-24 19:26 git Note Added: 0038857
2015-03-24 19:31 Roman Lygin Note Added: 0038858
2015-03-24 19:31 Roman Lygin Status new => resolved
2015-03-24 19:32 Roman Lygin Note Added: 0038859
2015-03-25 15:32 msv Note Added: 0038891
2015-03-25 15:32 msv Assigned To msv => bugmaster
2015-03-25 15:32 msv Status resolved => reviewed
2015-03-25 15:36 mkv Assigned To bugmaster => apv
2015-03-30 14:30 apv Note Added: 0038978
2015-03-30 14:30 apv Assigned To apv => msv
2015-03-30 14:30 apv Status reviewed => assigned
2015-03-30 17:33 git Note Added: 0039000
2015-04-01 10:11 msv Note Added: 0039070
2015-04-01 10:11 msv Assigned To msv => Roman Lygin
2015-04-01 10:19 abv Note Added: 0039072
2015-04-01 10:30 msv Note Added: 0039074
2015-04-07 15:08 Roman Lygin Note Added: 0039310
2015-04-08 18:06 git Note Added: 0039381
2015-04-08 18:11 msv Note Added: 0039382
2015-04-08 18:12 msv Note Edited: 0039382
2015-04-08 18:13 msv Note Edited: 0039382
2015-04-08 18:13 msv Note Edited: 0039382
2015-04-17 10:29 git Note Added: 0039943
2015-04-17 11:13 Roman Lygin Note Added: 0039944
2015-04-17 11:13 Roman Lygin Assigned To Roman Lygin => msv
2015-04-17 11:13 Roman Lygin Status assigned => feedback
2015-04-17 11:19 Roman Lygin Note Added: 0039945
2015-04-17 14:54 msv Note Added: 0039956
2015-04-17 14:54 msv Assigned To msv => Roman Lygin
2015-04-17 15:05 msv Note Added: 0039957
2015-04-17 15:24 git Note Added: 0039958
2015-04-17 15:32 git Note Added: 0039962
2015-04-17 16:15 Roman Lygin Note Added: 0039970
2015-04-17 16:15 Roman Lygin Assigned To Roman Lygin => msv
2015-04-17 16:15 Roman Lygin Status feedback => resolved
2015-04-17 16:16 Roman Lygin File Added:
2015-04-17 18:45 msv Note Added: 0039998
2015-04-17 18:46 msv Note Edited: 0039998
2015-04-17 18:47 msv Assigned To msv => Roman Lygin
2015-04-17 18:53 msv Note Added: 0039999
2015-04-17 18:53 msv Status resolved => assigned
2015-04-18 16:08 git Note Added: 0040024
2015-04-18 18:12 abv Test case number => bugs moddata_2 bug253
2015-04-18 18:12 abv Note Added: 0040025
2015-04-18 18:12 abv Assigned To Roman Lygin => bugmaster
2015-04-18 18:12 abv Priority normal => high
2015-04-18 18:12 abv Status assigned => resolved
2015-04-18 18:12 abv Target Version => 6.9.0
2015-04-18 18:13 abv Note Added: 0040026
2015-04-18 18:13 abv Status resolved => reviewed
2015-04-20 13:15 Roman Lygin Note Added: 0040044
2015-04-20 21:31 mkv Assigned To bugmaster => mkv
2015-04-21 15:18 msv Note Added: 0040074
2015-04-21 15:19 msv File Added: 0002-Make-the-same-patch-for-3d-curve-and-surface.patch
2015-04-21 15:20 msv Note Added: 0040075
2015-04-23 19:07 mkv Note Added: 0040180
2015-04-23 19:07 git Note Added: 0040181
2015-04-23 19:08 mkv Note Added: 0040182
2015-04-23 19:08 mkv Assigned To mkv => msv
2015-04-23 19:08 mkv Status reviewed => feedback
2015-04-23 19:09 mkv Test case number bugs moddata_2 bug253 => bugs moddata_2(013) bug253, bugs moddata_3(014) bug25971
2015-04-24 11:58 msv Note Added: 0040199
2015-04-24 11:58 msv Assigned To msv => bugmaster
2015-04-24 11:58 msv Status feedback => reviewed
2015-04-24 15:50 mkv Assigned To bugmaster => mkv
2015-04-28 20:52 mkv Note Added: 0040390
2015-04-28 20:52 mkv Assigned To mkv => bugmaster
2015-04-28 20:52 mkv Status reviewed => tested
2015-05-07 11:18 bugmaster Changeset attached => occt master 7b1c1b7c
2015-05-07 11:18 bugmaster Status tested => verified
2015-05-07 11:18 bugmaster Resolution open => fixed
2015-05-14 15:28 aiv Status verified => closed
2015-05-14 15:30 aiv Fixed in Version => 6.9.0
2015-05-14 16:32 git Note Added: 0041037
2015-05-14 16:32 git Note Added: 0041038
2015-05-14 16:32 git Note Added: 0041039