Bug 1231263 - slic3r-1.1.7-4.fc23 FTBFS with perl-5.22: 'W direction' t/angles.t test fails
Summary: slic3r-1.1.7-4.fc23 FTBFS with perl-5.22: 'W direction' t/angles.t test fails
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: slic3r
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miro Hrončok
QA Contact: Fedora Extras Quality Assurance
URL: https://koji.fedoraproject.org/koji/b...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-12 14:10 UTC by Petr Pisar
Modified: 2015-07-07 14:52 UTC (History)
2 users (show)

Fixed In Version: slic3r-1.2.9-1.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-01 12:21:14 UTC
Type: Bug


Attachments (Terms of Use)

Description Petr Pisar 2015-06-12 14:10:03 UTC
slic3r-1.1.7-4.fc23 fails to build with perl-5.22 because a test fails:

/builddir/build/BUILD/Slic3r-1.1.7
+ cd -
+ SLIC3R_NO_AUTO=1
+ perl Build.PL installdirs=vendor
#   Failed test 'W direction'
#   at t/angles.t line 47.
#          got: '3.14159265358979'
#     expected: '0'
# Looks like you failed 1 test of 34.
t/angles.t ........... 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/34 subtests

Comment 1 Miro Hrončok 2015-06-12 19:32:59 UTC
Note: This only happened on i686 and the test passed on x86_64.

Comment 2 Miro Hrončok 2015-06-12 20:30:12 UTC
The code that gets executed here is (simplified):

C++:
    #define PI 3.141592653589793238
    ...
    double atan2 = atan2(0-0,0-10);
    // note: atan2 is mathematically speaking an actual pi now
    return (atan2 == PI) ? 0
        : (atan2 < 0) ? (atan2 + PI)
        : atan2;

The routine returns 0 on x86_64 because the (atan2 == PI) condition passes.

On i686 it returns something else (3.14159265358979 ?) as the condition somehow doesn't pass.



But when I take the failing test:

    is line_direction([ [10, 0], [0, 0]  ]), (0),      'W direction';

and change it to:

    is line_direction([ [10, 0], [0, 0]  ]), (PI),     'W direction';

the test passes on i686, so the routine returned PI, which should not be possible.

It seems that the comparison (atan2 == PI) was false in C++, but true in Perl.

This sample program however:

    #include <iostream>
    #include <iomanip>
    #include <math.h>
    #define PI 3.141592653589793238
    int main(int argc, char **argv)
    {
      double pi = atan2(0, -10);
      std::cout << std::setprecision(35) << pi;
      if (pi == PI) std::cout << " == ";
      else std::cout << " != ";
      std::cout << PI << std::endl;
      return 0;
    }

Produces:

    3.1415926535897931159979634685441852 == 3.1415926535897931159979634685441852

in rawhide i686 mock. My head hurts :(

Comment 3 Petr Pisar 2015-06-15 06:59:57 UTC
Rounding error? Is the manually defined constant PI representable on i686? Could you consider using M_PI constant provided by <math.h>?

Also if FPU is involved, there are different modes for handling saturation and other corner cases. Maybe perl or slic3r sets them in different mode that the other expects.

Comment 4 Miro Hrončok 2015-06-15 07:57:00 UTC
Probably a rounding error, yes.

It's not representable on any arch (considering i686 and x86_64), also as far as I know doubles are represented the same way on both.

Using M_PI doesn't help.

Comment 5 Miro Hrončok 2015-07-01 12:21:14 UTC
Recent version 1.2.9 does not suffer from this problem anymore.


Note You need to log in before you can comment on or make changes to this bug.