MantisBT - Community
View Issue Details
0025971Community[OCCT] OCCT:Modeling Datapublic2015-03-23 12:202015-06-25 16:08
Roman Lygin 
bugmaster 
highminor 
closedfixed 
[OCCT] 6.8.0 
[OCCT] 6.9.0[OCCT] 6.9.0 
bugs moddata_2(013) bug253, bugs moddata_3(014) bug25971
0025971: Near B-Spline knots get merged after saving/restoring (exporting/importing)
A 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 dev.opencascade.org to solicit opinions on the best course of actions.
restore 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



No tags attached.
related to 0023175closed dbv Community Failed to segment a periodic B-Spline when parameter coincides with existing knot 
related to 0022989closed bugmaster Community BSplCLib::Reparametrize() fails on near knots 
zip a_328_1.zip (642) 2015-03-23 12:20
https://tracker.dev.opencascade.org/
zip Geom2d_BSplineCurve_streamlined_fix_excerpt.zip (1,309) 2015-04-17 16:16
https://tracker.dev.opencascade.org/
patch 0002-Make-the-same-patch-for-3d-curve-and-surface.patch (2,309) 2015-04-21 15:19
https://tracker.dev.opencascade.org/
Issue History
2015-03-23 12:20Roman LyginNew Issue
2015-03-23 12:20Roman LyginAssigned To => msv
2015-03-23 12:20Roman LyginFile Added: a_328_1.zip
2015-03-24 17:08Roman LyginRelationship addedrelated to 0023175
2015-03-24 17:11Roman LyginRelationship addedrelated to 0022989
2015-03-24 19:26gitNote Added: 0038857
2015-03-24 19:31Roman LyginNote Added: 0038858
2015-03-24 19:31Roman LyginStatusnew => resolved
2015-03-24 19:32Roman LyginNote Added: 0038859
2015-03-25 15:32msvNote Added: 0038891
2015-03-25 15:32msvAssigned Tomsv => bugmaster
2015-03-25 15:32msvStatusresolved => reviewed
2015-03-25 15:36mkvAssigned Tobugmaster => apv
2015-03-30 14:30apvNote Added: 0038978
2015-03-30 14:30apvAssigned Toapv => msv
2015-03-30 14:30apvStatusreviewed => assigned
2015-03-30 17:33gitNote Added: 0039000
2015-04-01 10:11msvNote Added: 0039070
2015-04-01 10:11msvAssigned Tomsv => Roman Lygin
2015-04-01 10:19abvNote Added: 0039072
2015-04-01 10:30msvNote Added: 0039074
2015-04-07 15:08Roman LyginNote Added: 0039310
2015-04-08 18:06gitNote Added: 0039381
2015-04-08 18:11msvNote Added: 0039382
2015-04-08 18:12msvNote Edited: 0039382bug_revision_view_page.php?bugnote_id=39382#r9861
2015-04-08 18:13msvNote Edited: 0039382bug_revision_view_page.php?bugnote_id=39382#r9862
2015-04-08 18:13msvNote Edited: 0039382bug_revision_view_page.php?bugnote_id=39382#r9863
2015-04-17 10:29gitNote Added: 0039943
2015-04-17 11:13Roman LyginNote Added: 0039944
2015-04-17 11:13Roman LyginAssigned ToRoman Lygin => msv
2015-04-17 11:13Roman LyginStatusassigned => feedback
2015-04-17 11:19Roman LyginNote Added: 0039945
2015-04-17 14:54msvNote Added: 0039956
2015-04-17 14:54msvAssigned Tomsv => Roman Lygin
2015-04-17 15:05msvNote Added: 0039957
2015-04-17 15:24gitNote Added: 0039958
2015-04-17 15:32gitNote Added: 0039962
2015-04-17 16:15Roman LyginNote Added: 0039970
2015-04-17 16:15Roman LyginAssigned ToRoman Lygin => msv
2015-04-17 16:15Roman LyginStatusfeedback => resolved
2015-04-17 16:16Roman LyginFile Added: Geom2d_BSplineCurve_streamlined_fix_excerpt.zip
2015-04-17 18:45msvNote Added: 0039998
2015-04-17 18:46msvNote Edited: 0039998bug_revision_view_page.php?bugnote_id=39998#r10090
2015-04-17 18:47msvAssigned Tomsv => Roman Lygin
2015-04-17 18:53msvNote Added: 0039999
2015-04-17 18:53msvStatusresolved => assigned
2015-04-18 10:28abvRelationship addedrelated to 0000253
2015-04-18 16:08gitNote Added: 0040024
2015-04-18 18:12abvTest case number => bugs moddata_2 bug253
2015-04-18 18:12abvNote Added: 0040025
2015-04-18 18:12abvAssigned ToRoman Lygin => bugmaster
2015-04-18 18:12abvPrioritynormal => high
2015-04-18 18:12abvStatusassigned => resolved
2015-04-18 18:12abvTarget Version => 6.9.0
2015-04-18 18:13abvNote Added: 0040026
2015-04-18 18:13abvStatusresolved => reviewed
2015-04-20 13:15Roman LyginNote Added: 0040044
2015-04-20 21:31mkvAssigned Tobugmaster => mkv
2015-04-21 15:18msvNote Added: 0040074
2015-04-21 15:19msvFile Added: 0002-Make-the-same-patch-for-3d-curve-and-surface.patch
2015-04-21 15:20msvNote Added: 0040075
2015-04-23 19:07mkvNote Added: 0040180
2015-04-23 19:07gitNote Added: 0040181
2015-04-23 19:08mkvNote Added: 0040182
2015-04-23 19:08mkvAssigned Tomkv => msv
2015-04-23 19:08mkvStatusreviewed => feedback
2015-04-23 19:09mkvTest case numberbugs moddata_2 bug253 => bugs moddata_2(013) bug253, bugs moddata_3(014) bug25971
2015-04-24 11:58msvNote Added: 0040199
2015-04-24 11:58msvAssigned Tomsv => bugmaster
2015-04-24 11:58msvStatusfeedback => reviewed
2015-04-24 15:50mkvAssigned Tobugmaster => mkv
2015-04-28 20:52mkvNote Added: 0040390
2015-04-28 20:52mkvAssigned Tomkv => bugmaster
2015-04-28 20:52mkvStatusreviewed => tested
2015-05-07 11:18bugmasterChangeset attached => occt master 7b1c1b7c
2015-05-07 11:18bugmasterStatustested => verified
2015-05-07 11:18bugmasterResolutionopen => fixed
2015-05-14 15:28aivStatusverified => closed
2015-05-14 15:30aivFixed in Version => 6.9.0
2015-05-14 16:32gitNote Added: 0041037
2015-05-14 16:32gitNote Added: 0041038
2015-05-14 16:32gitNote Added: 0041039
2015-06-25 16:08msvRelationship addedrelated to 0026374

Notes
(0038857)
git   
2015-03-24 19:26   
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)
(0038858)
Roman Lygin   
2015-03-24 19:31   
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.
(0038859)
Roman Lygin   
2015-03-24 19:32   
Another candidate for alignment is ShapeConstruct_Curve::FixKnots().
(0038891)
msv   
2015-03-25 15:32   
Reviewed.
(0038978)
apv   
2015-03-30 14:30   
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)

Regressions/Differences:
http://occt-tests/CR25971-master-occt-64/Debian60-64/summary.html [^]
http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/summary.html [^]
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:
http://occt-tests/CR25971-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html [^]
bugs vis bug24717
(0039000)
git   
2015-03-30 17:33   
Branch CR25971 has been updated forcibly by msv.

SHA-1: b46ddd23f10d84485997875a013825fbee5f450d
(0039070)
msv   
2015-04-01 10:11   
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.
(0039072)
abv   
2015-04-01 10:19   
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.
(0039074)
msv   
2015-04-01 10:30   
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.
(0039310)
Roman Lygin   
2015-04-07 15:08   
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.
(0039381)
git   
2015-04-08 18:06   
Branch CR25971 has been updated forcibly by msv.

SHA-1: 35dd50465f24604f938c5cc074a6b4b19f9e5e6d
(0039382)
msv   
2015-04-08 18:11   
(edited on: 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.

(0039943)
git   
2015-04-17 10:29   
Branch CR25971_1 has been created by Roman Lygin.

SHA-1: 43ebf89c220b4bbbabdf78ccb907f3b0b594e789


No new revisions were added by this update.
(0039944)
Roman Lygin   
2015-04-17 11:13   
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
(0039945)
Roman Lygin   
2015-04-17 11:19   
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.28318530717958
6.28318530717958

6. Restoring throws an exception.
(0039956)
msv   
2015-04-17 14:54   
Roman, sorry but I have not found the new branch in the repository.
(0039957)
msv   
2015-04-17 15:05   
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.
(0039958)
git   
2015-04-17 15:24   
Branch CR25971_2 has been created by Roman Lygin.

SHA-1: 43ebf89c220b4bbbabdf78ccb907f3b0b594e789


No new revisions were added by this update.
(0039962)
git   
2015-04-17 15:32   
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)

(0039970)
Roman Lygin   
2015-04-17 16:15   
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.
(0039998)
msv   
2015-04-17 18:45   
(edited on: 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.

(0039999)
msv   
2015-04-17 18:53   
Also, the similar simple change can be done in surface methods:
Geom_BSplineSurface::Segment
Geom_BSplineSurface::CheckAndSegment
(0040024)
git   
2015-04-18 16:08   
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)

(0040025)
abv   
2015-04-18 18:12   
I have pushed the fix rebased on current master and with corrected test cases to branch CR25971_2
(0040026)
abv   
2015-04-18 18:13   
Reviewed, please test
(0040044)
Roman Lygin   
2015-04-20 13:15   
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.
Roman
(0040074)
msv   
2015-04-21 15:18   
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)
(0040075)
msv   
2015-04-21 15:20   
I have uploaded the patch mentioned above as the file 0002-Make-the-same-patch-for-3d-curve-and-surface.patch.
(0040180)
mkv   
2015-04-23 19:07   
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)

Regressions/Differences:
No regressions/differences

Testing cases:
http://occt-tests/CR25971-2-master-occt-64/Debian60-64/bugs/moddata_3/bug25971.html [^]
http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/bugs/moddata_3/bug25971.html [^]
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.
http://occt-tests/CR25971-2-master-occt-64/Debian60-64/diff-Debian60-64.html [^]
http://occt-tests/CR25971-2-master-occt-64/Windows-64-VC10/diff-Windows-64-VC10.html [^]
IMAGE de step_2 C9: C9.png differs
IMAGE de step_3 D1: D1.png differs
(0040181)
git   
2015-04-23 19:07   
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

(0040182)
mkv   
2015-04-23 19:08   
Dear msv,
could you please review following test case
bugs moddata_3(014) bug25971

This test case is OK on current master also.
(0040199)
msv   
2015-04-24 11:58   
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.
(0040390)
mkv   
2015-04-28 20:52   
Dear BugMaster,
Branch CR25971_2 is TESTED.
(0041037)
git   
2015-05-14 16:32   
Branch CR25971 has been deleted by inv.

SHA-1: 35dd50465f24604f938c5cc074a6b4b19f9e5e6d
(0041038)
git   
2015-05-14 16:32   
Branch CR25971_1 has been deleted by inv.

SHA-1: 7d1c80335fc067aac43fb2b6200f4e0b81789654
(0041039)
git   
2015-05-14 16:32   
Branch CR25971_2 has been deleted by inv.

SHA-1: ff612506d8081ac39d7c836ae37c7db38f0f025a