Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6.3.0 Tests fail on Alpine Linux x86 (musl libc) #1906

Closed
russkel opened this issue Feb 4, 2020 · 30 comments
Closed

6.3.0 Tests fail on Alpine Linux x86 (musl libc) #1906

russkel opened this issue Feb 4, 2020 · 30 comments
Labels

Comments

@russkel
Copy link

@russkel russkel commented Feb 4, 2020

Example of problem

I am in the process of fixing the Alpine Linux proj package and have found that is solely fails on the x86 platform.

The following tests FAILED:
	  2 - Builtins (Failed)
	  3 - Builtins2 (Failed)
	  6 - Ellipsoid (Failed)
	 31 - testvarious (Failed)
Errors while running CTest
test 2
      Start  2: Builtins

2: Test command: /builds/russkel/aports/community/proj/src/proj-6.3.0/bin/gie "/builds/russkel/aports/community/proj/src/proj-6.3.0/test/gie/builtins.gie"
2: Environment variables: 
2:  PROJ_LIB=/builds/russkel/aports/community/proj/src/proj-6.3.0/data
2: Test timeout computed to be: 10000000
2: -------------------------------------------------------------------------------
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -21: conic lat_1 = -lat_2
2: proj_create: Error -6: effective eccentricity < 0 or >= 1.
2: proj_create: Error -21: conic lat_1 = -lat_2
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -21: conic lat_1 = -lat_2
2: proj_create: Error -30: h <= 0 or h > 1e10 * a
2: proj_create: Error -30: h <= 0 or h > 1e10 * a
2: proj_create: Error -58: argument not numerical or out of range
2: proj_create: Error -55: lat_0 = 0
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -27: W <= 0 or M <= 0
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -6: effective eccentricity < 0 or >= 1.
2: proj_create: Error -6: effective eccentricity < 0 or >= 1.
2: proj_create: Error -32: lat_1=lat_2 or lat_1=0 or lat_2=90
2: proj_create: Error -32: lat_1=lat_2 or lat_1=0 or lat_2=90
2: proj_create: Error -32: lat_1=lat_2 or lat_1=0 or lat_2=90
2: proj_create: Error -32: lat_1=lat_2 or lat_1=0 or lat_2=90
2: proj_create: Error -32: lat_1=lat_2 or lat_1=0 or lat_2=90
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -30: h <= 0 or h > 1e10 * a
2: proj_create: Error -30: h <= 0 or h > 1e10 * a
2: proj_create: Error -37: failed to find projection to be rotated
2: proj_create: Error -33: lat_0 = 0 or 90 or alpha = 90
2: proj_create: Error -6: effective eccentricity < 0 or >= 1.
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
2: proj_create: Error 12: Out of memory
2: proj_create: Error -32: lat_1=lat_2 or lat_1=0 or lat_2=90
2: proj_create: Error -33: lat_0 = 0 or 90 or alpha = 90
2: Reading file '/builds/russkel/aports/community/proj/src/proj-6.3.0/test/gie/builtins.gie'
2: errno=-14, expected=-6
2:      -----
2:      FAILURE in builtins.gie(2489):
2:      expected: 0 4886594.2207
2:      got:      -nan   -nan
2:      deviation:  nan mm,  expected:  0.100000 mm
2: errno=0, expected=-6
2:      -----
2:      FAILURE in builtins.gie(4805):
2:      expected: 0.000000000000 8654720.000000000000
2:      got:      0.000000000000   8654720.465063288808
2:      deviation:  465.063289 mm,  expected:  0.100000 mm
2:      -----
2:      FAILURE in builtins.gie(4811):
2:      expected: 0.000000000000 -8654720.000000000000
2:      got:      0.000000000000   -8654720.465063288808
2:      deviation:  465.063289 mm,  expected:  0.100000 mm
2:      -----
2:      FAILURE in builtins.gie(5686):
2:      expected: 223395.249543407 111704.596633675
2:      got:      223395.249543474842   111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2:      -----
2:      FAILURE in builtins.gie(5689):
2:      expected: 223395.249543407 -111704.596633675
2:      got:      223395.249543474842   -111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2:      -----
2:      FAILURE in builtins.gie(5691):
2:      expected: -223395.249543407 111704.596633675
2:      got:      -223395.249543474842   111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2:      -----
2:      FAILURE in builtins.gie(5693):
2:      expected: -223395.249543407 -111704.596633675
2:      got:      -223395.249543474842   -111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2: errno=0, expected=-20
2: -------------------------------------------------------------------------------
2: total: 1728 tests succeeded,  0 tests skipped, 10 tests FAILED!
2: -------------------------------------------------------------------------------
 2/41 Test  #2: Builtins .........................***Failed    0.05 sec
test 3
      Start  3: Builtins2

3: Test command: /builds/russkel/aports/community/proj/src/proj-6.3.0/bin/gie "/builds/russkel/aports/community/proj/src/proj-6.3.0/test/gie/more_builtins.gie"
3: Environment variables: 
3:  PROJ_LIB=/builds/russkel/aports/community/proj/src/proj-6.3.0/data
3: Test timeout computed to be: 10000000
3: -------------------------------------------------------------------------------
3: proj_create: Error -1: no arguments in initialization list
3: proj_create: Error -54: missing required arguments
3: proj_create: Error -50: malformed pipeline
3: proj_create: Error -50: malformed pipeline
3: proj_create: nested pipeline not supported
3: proj_create: +step found outside pipeline
3: proj_create: Error -50: malformed pipeline
3: proj_create: Error -1: no arguments in initialization list
3: proj_create: Error -38: failed to load datum shift file
3: proj_create: Error -38: failed to load datum shift file
3: proj_create: Error -1: no arguments in initialization list
3: proj_create: Error -54: missing required arguments
3: proj_create: Error -58: argument not numerical or out of range
3: proj_create: Error -58: argument not numerical or out of range
3: proj_create: Error -58: argument not numerical or out of range
3: proj_create: Error -58: argument not numerical or out of range
3: proj_create: Error -54: missing required arguments
3: proj_create: Error -51: unit conversion factor must be > 0
3: proj_create: Error -51: unit conversion factor must be > 0
3: proj_create: Error -22: lat_0, lat_1 or lat_2 >= 90
3: Reading file '/builds/russkel/aports/community/proj/src/proj-6.3.0/test/gie/more_builtins.gie'
3:      -----
3:      FAILURE in more_builtins.gie(838):
3:      expected: 0 90 0
3:      got:      0.000000000000   0.000000000000   -6378137.000000000
3:      deviation:  999999999.999000 mm,  expected:  1.000000 mm
3:      -----
3:      FAILURE in more_builtins.gie(841):
3:      expected: 0 -90 0
3:      got:      0.000000000000   0.000000000000   -6378137.000000000
3:      deviation:  999999999.999000 mm,  expected:  1.000000 mm
3: -------------------------------------------------------------------------------
3: total: 157 tests succeeded,  0 tests skipped,  2 tests FAILED!
3: -------------------------------------------------------------------------------
 3/41 Test  #3: Builtins2 ........................***Failed    0.04 sec

test 6
      Start  6: Ellipsoid

6: Test command: /builds/russkel/aports/community/proj/src/proj-6.3.0/bin/gie "/builds/russkel/aports/community/proj/src/proj-6.3.0/test/gie/ellipsoid.gie"
6: Environment variables: 
6:  PROJ_LIB=/builds/russkel/aports/community/proj/src/proj-6.3.0/data
6: Test timeout computed to be: 10000000
6: -------------------------------------------------------------------------------
6: proj_create: Error -9: unknown elliptical parameter name
6: proj_create: Error -13: major axis or radius = 0 or not given
6: proj_create: Error -13: major axis or radius = 0 or not given
6: proj_create: Error -13: major axis or radius = 0 or not given
6: proj_create: Error -13: major axis or radius = 0 or not given
6: proj_create: unrecognized format / unknown name
6: proj_create: unrecognized format / unknown name
6: proj_create: Error -11: |radius reference latitude| > 90
6: proj_create: Error -10: reciprocal flattening (1/f) = 0
6: proj_create: Error -6: effective eccentricity < 0 or >= 1.
6: proj_create: Error -6: effective eccentricity < 0 or >= 1.
6: proj_create: Error -6: effective eccentricity < 0 or >= 1.
6: proj_create: Error -6: effective eccentricity < 0 or >= 1.
6: proj_create: Error -6: effective eccentricity < 0 or >= 1.
6: proj_create: Error -6: effective eccentricity < 0 or >= 1.
6: Reading file '/builds/russkel/aports/community/proj/src/proj-6.3.0/test/gie/ellipsoid.gie'
6:      -----
6:      FAILURE in ellipsoid.gie(48):
6:      expected: 1335833.8895192828 7326837.7148738774
6:      got:      1335833.889519282850   -7326837.714873872697
6:      deviation:  999999999.999000 mm,  expected:  0.000010 mm
6:      -----
6:      FAILURE in ellipsoid.gie(120):
6:      got errno ref_rad_larger_than_90 (-11): |radius reference latitude| > 90
6:      expected invalid_eccentricity (-6):  effective eccentricity < 0 or >= 1.
6: -------------------------------------------------------------------------------
6: total: 35 tests succeeded,  0 tests skipped,  2 tests FAILED!
6: -------------------------------------------------------------------------------
 6/41 Test  #6: Ellipsoid ........................***Failed    0.10 sec


31: Test command: /bin/bash "/builds/russkel/aports/community/proj/src/proj-6.3.0/test/cli/testvarious" "/builds/russkel/aports/community/proj/src/proj-6.3.0/bin/cs2cs"
31: Environment variables: 
31:  PROJ_LIB=/builds/russkel/aports/community/proj/src/proj-6.3.0/data
31: Test timeout computed to be: 10000000
31: ============================================
31: Running /builds/russkel/aports/community/proj/src/proj-6.3.0/test/cli/testvarious using /builds/russkel/aports/community/proj/src/proj-6.3.0/bin/cs2cs:
31: ============================================
31: doing tests into file tv_out, please wait
31: diff tv_out with tv_out.dist
31: --- tv_out
31: +++ /builds/russkel/aports/community/proj/src/proj-6.3.0/test/cli/tv_out.dist
31: @@ -41,7 +41,7 @@
31:  6378137.00      -0.00 0.00	0dE	0dN 0.000
31:  6378147.00      -0.00 0.00	0dE	0dN 10.000
31:  861996.98       -4434590.01 4487348.41	79dW	45dN 0.001
31: -0.00    -0.00 6356752.31	0dE	0dN -6378137.000
31: +0.00    -0.00 6356752.31	0dE	90dN -0.004
31:  #############################################################
31:  Test conversion from geocentric latlong to geodetic latlong
31:  0d00'00.000"W 0d00'00.000"N 0.0	0dE	0dN 0.000
31: @@ -97,9 +97,9 @@
31:  15d4'42.357"E	14d48'56.372"N 0.000	3999967.33	1999855.31 0.00
31:  ##############################################################
31:  Test robinson projection (#113)
31: --30 40	-2612096.11	4276349.63 0.00
31: --35 45	-2963455.37	4805075.13 0.00
31: -20 40	1741397.41	4276349.63 0.00
31: +-30 40	-2612095.95	4276351.58 0.00
31: +-35 45	-2963455.42	4805073.65 0.00
31: +20 40	1741397.30	4276351.58 0.00
31:  -2612095.95     4276351.58 0.00	30d0'0.004"W	40d0'0.066"N 0.000
31:  -2963455.42     4805073.65 0.00	35dW	45dN 0.000
31:  1741397.30      4276351.58 0.00	20d0'0.002"E	40d0'0.066"N 0.000
31: 
31: PROBLEMS HAVE OCCURRED
31: test file tv_out saved

I have uploaded the entire build log from the CI system.

job.log

Environment Information

  • PROJ version (proj) 6.3.0
  • Alpine Linux Edge on x86

Installation method

  • Compiling from source
@russkel russkel added the bug label Feb 4, 2020
@rouault
Copy link
Member

@rouault rouault commented Feb 4, 2020

This is most certainly a defect in the musl libc implementation of some of the math functions that PROJ uses

@russkel
Copy link
Author

@russkel russkel commented Feb 4, 2020

I thought we'd see the defects extend to other archs as well. Out of the 7 or so architectures Alpine compiles for, it's only x86 that it fails on. I guess I'll post this onto the musl libc mailing list.

@richfelker
Copy link

@richfelker richfelker commented Feb 4, 2020

By x86 do you mean 32-bit or x86_64?

@richfelker
Copy link

@richfelker richfelker commented Feb 4, 2020

Also are you sure it's math? Naively looking at the error messages, it looks more like somehow the input/arguments didn't get processed, at least for tests 3 and 6. But I haven't read any of the relevant source yet.

@nsz-arm
Copy link

@nsz-arm nsz-arm commented Feb 4, 2020

on musl non-nearest rounding mode sin/cos/tan are known to have issues and most of complex math in all rounding modes (it's a naive implementation that works for normal range inputs i think but not for difficult cases).

other musl math stuff should work (guaranteed low ulp error bounds).

@russkel
Copy link
Author

@russkel russkel commented Feb 4, 2020

By x86 do you mean 32-bit or x86_64?

Yes, x86 32bit. 64b has no issues with these tests.

@russkel
Copy link
Author

@russkel russkel commented Feb 4, 2020

Also are you sure it's math? Naively looking at the error messages, it looks more like somehow the input/arguments didn't get processed, at least for tests 3 and 6. But I haven't read any of the relevant source yet.

Good point. I will post the output of the x86_64 tests and see if the errors are different. Keep in mind the errors are only showing since I have verbosity turned on for ctest. It's possible some tests were meant to error?

@kbevers
Copy link
Member

@kbevers kbevers commented Feb 4, 2020

Ignore the proj_create: Error ... lines, they are supposed to be there. They are issued when we are testing if failures are correctly captured and handled by the software.

@richfelker
Copy link

@richfelker richfelker commented Feb 4, 2020

@kbevers: From a standpoint of being familiar with the code, can you offer any insight on what math library functions might be called in the code paths that are failing? Unless it's an issue with excess precision (unique to i386 and m68k), if it's a bug in musl it pretty much has to be one of the functions with i386-specific versions, listed here: https://git.musl-libc.org/cgit/musl/tree/src/math/i386?id=v1.1.24

@kbevers
Copy link
Member

@kbevers kbevers commented Feb 4, 2020

@richfelker I can try. I haven't looked much at this, but here's a few places to start.

For the "3" failures, the test is exercising this function, so a likely candidate for the problem:

/*********************************************************************/
static PJ_LPZ geodetic (PJ_XYZ cart, PJ *P) {
/*********************************************************************/
double N, p, theta, c, s;
PJ_LPZ lpz;
/* Perpendicular distance from point to Z-axis (HM eq. 5-28) */
p = hypot (cart.x, cart.y);
/* HM eq. (5-37) */
theta = atan2 (cart.z * P->a, p * P->b);
/* HM eq. (5-36) (from BB, 1976) */
c = cos(theta);
s = sin(theta);
lpz.phi = atan2 (cart.z + P->e2s*P->b*s*s*s, p - P->es*P->a*c*c*c);
if( fabs(lpz.phi) > M_HALFPI ) {
// this happen on non-sphere ellipsoid when x,y,z is very close to 0
// there is no single solution to the cart->geodetic conversion in
// that case, so arbitrarily pickup phi = 0.
lpz.phi = 0;
}
lpz.lam = atan2 (cart.y, cart.x);
N = normal_radius_of_curvature (P->a, P->es, lpz.phi);
c = cos(lpz.phi);
if (fabs(c) < 1e-6) {
/* poleward of 89.99994 deg, we avoid division by zero */
/* by computing the height as the cartesian z value */
/* minus the geocentric radius of the Earth at the given */
/* latitude */
double r = geocentric_radius (P->a, P->b, lpz.phi);
lpz.z = fabs (cart.z) - r;
}
else
lpz.z = p / c - N;
return lpz;
}

For the "6" test the problem is likely somewhere in https://github.com/OSGeo/PROJ/blob/master/src/ell_set.cpp. At least for the last failure. The first one may be caused by the "55s" in this gie test:

-------------------------------------------------------------------------------
Then try using a built in ellipsoid
-------------------------------------------------------------------------------
operation proj=merc ellps=GRS80
-------------------------------------------------------------------------------
tolerance 10 nm
accept 1 2
expect 111319.4907932736 221194.0771604237
accept 12 55s
expect 1335833.8895192828 7326837.7148738774
-------------------------------------------------------------------------------

Those are roughly the places that the tests are meant to check but there may be some other thing going when setting up transformations etc.

@richfelker
Copy link

@richfelker richfelker commented Feb 4, 2020

Thanks, this is helpful. I'll setup a build and see if I can catch it doing something weird under debugger.

@russkel
Copy link
Author

@russkel russkel commented Feb 4, 2020

@richfelker https://gitlab.alpinelinux.org/alpine/aports/merge_requests/3634 if you would like an Alpine Linux APKBUILD. Thanks a ton for looking into this.

@kbevers Helpful, thank you.

@richfelker
Copy link

@richfelker richfelker commented Feb 4, 2020

In the test that fails, at line 165 it takes the branch and sets lpz.phi to 0. I'm not sure yet if this is a bug on our side or on yours.

@richfelker
Copy link

@richfelker richfelker commented Feb 4, 2020

OK, the cause of atan2 not truncating excess precision. I forget the history of the requirements, but historically it was underspecified whether the standard library functions returning float or double were required to do so, but my current understanding is that current or future standards require it, so we should fix this.

In theory it could be worked around by explicitly dropping the excess precision with a (double) cast in the caller, but this doesn't seem to work, probably because GCC does not use or support -fexcess-precision=standard in C++. Of course that means your C++ code is going to be subject to nasty compiler bugs around numerical stability; for example on targets without -fmath-errno or with explicit -fno-math-errno, I think GCC could use a builtin for atan2 and end up having the excess precision, breaking things again even if we fix it in musl. So you really probably need to do something to make this code safe against the badness of GCC.

I don't know the right fix here, but the current code is numerically unstable.

@richfelker
Copy link

@richfelker richfelker commented Feb 5, 2020

Note also that p - P->es*P->a*c*c*c can actually be negative when the intended exact value would be zero, since theta is approximate and therefore cos(theta) is not exactly zero. This can then make the angle greater than 90 degrees when it should be exactly 90, thereby triggering the special case. I'm not sure if this is relevant to the test case that's failing (I think the y argument is sufficient in magnitude that it dosn't matter), but it can happen for differnet inputs; I think that's what the comment is getting at.

I suspect the right thing to do here would be clipping to 90 degrees rather than arbitrarily choosing 0, so that it's not a discontinuous arbitrary choice.

kbevers added a commit to kbevers/PROJ that referenced this issue Feb 5, 2020
This should avoid issues with numerical stability as uncovered in
OSGeo#1906.

Practically speaking this change isn't going to affect real life
scenarios since the position of the center of the Earth is rarely
expressed in geodetic coordinates.
@kbevers
Copy link
Member

@kbevers kbevers commented Feb 5, 2020

I suspect the right thing to do here would be clipping to 90 degrees rather than arbitrarily choosing 0, so that it's not a discontinuous arbitrary choice.

I've implemented that in #1912. I don't know if it will fix the problem at hand but it is worth a try. Functionally it it doesn't matter if we use this approach or the original one that sets lpz.phi = 0.0.

As for the rest of the errors reported above, there may be similar issues at play. I haven't looked into them as I haven't got any means of testing it anyway. I can provide a gie file that only exercises the above failures if that is helpful.

@russkel
Copy link
Author

@russkel russkel commented Feb 5, 2020

Test 3 no longer fails with #1912 applied.

3809 The following tests FAILED:
3810 	  2 - Builtins (Failed)
3811 	  6 - Ellipsoid (Failed)
3812 	 31 - testvarious (Failed)

kbevers added a commit to kbevers/PROJ that referenced this issue Feb 6, 2020
This should avoid issues with numerical stability as uncovered in
OSGeo#1906.

Practically speaking this change isn't going to affect real life
scenarios since the position of the center of the Earth is rarely
expressed in geodetic coordinates.
kbevers added a commit to kbevers/PROJ that referenced this issue Feb 6, 2020
This should avoid issues with numerical stability as uncovered in
OSGeo#1906.

Practically speaking this change isn't going to affect real life
scenarios since the position of the center of the Earth is rarely
expressed in geodetic coordinates.
@richfelker
Copy link

@richfelker richfelker commented Feb 6, 2020

What does the 55s mean in the failing test above? I'm looking into what functions might be broken still.

@richfelker
Copy link

@richfelker richfelker commented Feb 6, 2020

FYI disabling all of the i386 math asm in musl does not make the failure go away, so I suspect the remainder of these test failures may be bugs in PROJ not correctly handling FLT_EVAL_METHOD==2 (excess precision) or bugs in GCC (since it doesn't handle excess precision in a conforming way in C++ mode).

@richfelker
Copy link

@richfelker richfelker commented Feb 6, 2020

Additional info:

The first failure in test 31 is fixed by addressing the excess precision problem with atan (or on PROJ side) as described above.

The rest of the failures in test 31 are small deviations from expected result and probably due to excess precision (or GCC's or PROJ's mishandling of it). All the failures in test 2 also seem to be of this form.

The cause of the failures in test 6 aren't clear to me. The first one could be small error from excess precision causing something to fall on the wrong side of a branch cut, but it might very well be something else, too. I have no idea what the second one is.

At this point I don't think there's any further cause on musl's side, but I'm happy to look into it further if you turn up results that suggest it is on our side.

rouault added a commit to rouault/PROJ that referenced this issue Feb 6, 2020
Fix a few issues of OSGeo#1906 found when running the test suite
on Ubuntu 16.04 with gcc 5.5 -m32. When applied on top of
the fix of OSGeo#1912, make check succeeds
@rouault
Copy link
Member

@rouault rouault commented Feb 6, 2020

55 seconds, as in degrees minutes seconds?

No. Was a typo

See #1917 for additional fixes. Not completely sure they fix all issues you found, but at least, combined with #1912, they fix all test failures on my i386 environment

@russkel
Copy link
Author

@russkel russkel commented Feb 6, 2020

55 seconds, as in degrees minutes seconds?

No. Was a typo

See #1917 for additional fixes. Not completely sure they fix all issues you found, but at least, combined with #1912, they fix all test failures on my i386 environment

Yeah oops, deleted my reply.

I am firing off the build with #1917 applied as well. Will report back.

@russkel
Copy link
Author

@russkel russkel commented Feb 6, 2020

3802 The following tests FAILED:
3803 	  2 - Builtins (Failed)
3804 	 31 - testvarious (Failed)
3805 Errors while running CTest
2:      FAILURE in builtins.gie(4806):
2:      expected: 0.000000000000 8654720.000000000000
2:      got:      0.000000000000   8654720.465063288808
2:      deviation:  465.063289 mm,  expected:  0.100000 mm
2:      -----
2:      FAILURE in builtins.gie(4812):
2:      expected: 0.000000000000 -8654720.000000000000
2:      got:      0.000000000000   -8654720.465063288808
2:      deviation:  465.063289 mm,  expected:  0.100000 mm
2:      -----
2:      FAILURE in builtins.gie(5687):
2:      expected: 223395.249543407 111704.596633675
2:      got:      223395.249543474842   111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2:      -----
2:      FAILURE in builtins.gie(5690):
2:      expected: 223395.249543407 -111704.596633675
2:      got:      223395.249543474842   -111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2:      -----
2:      FAILURE in builtins.gie(5692):
2:      expected: -223395.249543407 111704.596633675
2:      got:      -223395.249543474842   111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2:      -----
2:      FAILURE in builtins.gie(5694):
2:      expected: -223395.249543407 -111704.596633675
2:      got:      -223395.249543474842   -111704.596082000367
2:      deviation:  0.551675 mm,  expected:  0.250000 mm
2: errno=0, expected=-20
2: -------------------------------------------------------------------------------
2: total: 1730 tests succeeded,  0 tests skipped,  7 tests FAILED!
2: -------------------------------------------------------------------------------
 2/41 Test  #2: Builtins .........................***Failed    0.05 sec

31: ============================================
31: Running /builds/russkel/aports/community/proj/src/proj-6.3.0/test/cli/testvarious using /builds/russkel/aports/community/proj/src/proj-6.3.0/bin/cs2cs:
31: ============================================
31: doing tests into file tv_out, please wait
31: diff tv_out with tv_out.dist
31: --- tv_out
31: +++ /builds/russkel/aports/community/proj/src/proj-6.3.0/test/cli/tv_out.dist
31: @@ -97,9 +97,9 @@
31:  15d4'42.357"E	14d48'56.372"N 0.000	3999967.33	1999855.31 0.00
31:  ##############################################################
31:  Test robinson projection (#113)
31: --30 40	-2612096.11	4276349.63 0.00
31: --35 45	-2963455.37	4805075.13 0.00
31: -20 40	1741397.41	4276349.63 0.00
31: +-30 40	-2612095.95	4276351.58 0.00
31: +-35 45	-2963455.42	4805073.65 0.00
31: +20 40	1741397.30	4276351.58 0.00
31:  -2612095.95     4276351.58 0.00	30d0'0.004"W	40d0'0.066"N 0.000
31:  -2963455.42     4805073.65 0.00	35dW	45dN 0.000
31:  1741397.30      4276351.58 0.00	20d0'0.002"E	40d0'0.066"N 0.000
31: 
31: PROBLEMS HAVE OCCURRED
31: test file tv_out saved

@richfelker
Copy link

@richfelker richfelker commented Feb 7, 2020

@russkel: #1917 is not yet merged. I think it will fix the remaining issues.

@russkel
Copy link
Author

@russkel russkel commented Feb 7, 2020

@russkel: #1917 is not yet merged. I think it will fix the remaining issues.

My APKBUILD includes 1917 as a patch:

120 >>> proj: Fetching fix-x86-tests.patch::https://github.com/OSGeo/PROJ/commit/19bfb4987a8085d3ec1c8f29423866f884fdbd1f.patch
121   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
122                                  Dload  Upload   Total   Spent    Left  Speed
123 100  2971    0  2971    0     0  12535      0 --:--:-- --:--:-- --:--:-- 12588

143 >>> proj: fix-x86-tests.patch
144 patching file src/projections/laea.cpp
145 patching file test/gie/builtins.gie
146 patching file test/gie/ellipsoid.gie

rouault added a commit to rouault/PROJ that referenced this issue Feb 7, 2020
Refs OSGeo#1906
Fix remaining issues of OSGeo#1906 (comment)
as found with gcc 8.2.0 -m32 -O2
@rouault
Copy link
Member

@rouault rouault commented Feb 7, 2020

c6eb8b6 added in #1917 should fix the last remaining issues. So this does not seem to be musl specific, but really gcc i386.

@russkel
Copy link
Author

@russkel russkel commented Feb 7, 2020

@rouault is there value in adding this particular setup to the CI matrix?

@russkel
Copy link
Author

@russkel russkel commented Feb 7, 2020

x86 is compiling and passing all checks now! Thanks for your help @rouault and @richfelker

Also apologies for attributing the errors to musl, @richfelker.

@richfelker
Copy link

@richfelker richfelker commented Feb 7, 2020

@russkel: Failure to drop excess precision from certain math lib functions was a bug in musl, and I'm glad that was brought to my attention. It's been fixed now. I think the clamping on PROJ's side is also right though, even if either fix alone is sufficient to make the problem go away - the numerical instability of the old code was not a good thing to have and could have broken in other ways.

Thanks too for verifying that the tests all pass now. It's good to know I'm not still looking for more bugs in musl.

@amonakov
Copy link

@amonakov amonakov commented Feb 7, 2020

Do people test PROJ on 32-bit x86 with Glibc? As far as I can tell, Glibc has similar behavior with excess precision returned from atan2 and for example acos as well, so I would expect that this issue would also surface there.

rouault added a commit to rouault/PROJ that referenced this issue Feb 7, 2020
Refs OSGeo#1906
Fix remaining issues of OSGeo#1906 (comment)
as found with gcc 8.2.0 -m32 -O2
kbevers added a commit that referenced this issue Feb 7, 2020
cart: Avoid discontinuity at poles in the inverse case (partial fix to #1906)
@kbevers kbevers closed this Feb 8, 2020
rouault pushed a commit to rouault/PROJ that referenced this issue Feb 8, 2020
This should avoid issues with numerical stability as uncovered in
OSGeo#1906.

Practically speaking this change isn't going to affect real life
scenarios since the position of the center of the Earth is rarely
expressed in geodetic coordinates.
rouault added a commit to rouault/PROJ that referenced this issue Feb 8, 2020
Fix a few issues of OSGeo#1906 found when running the test suite
on Ubuntu 16.04 with gcc 5.5 -m32. When applied on top of
the fix of OSGeo#1912, make check succeeds
rouault added a commit to rouault/PROJ that referenced this issue Feb 8, 2020
Refs OSGeo#1906
Fix remaining issues of OSGeo#1906 (comment)
as found with gcc 8.2.0 -m32 -O2
rouault added a commit that referenced this issue Feb 8, 2020
[Backport 6.3] fixes for #1906 (test failures on i386)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants