glibc 2.28 autopkgtest failures

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

glibc 2.28 autopkgtest failures

Michael Hudson-Doyle
tl;dr we should force things through :)

There are at the time of writing two autopkgtest failures preventing glibc from migrating: r-cran-rgenoud and python-cffi

The r-cran-genoud failure is mystifying in that I have no idea how the glibc version is affecting the package (it doesn't call many libc or libm functions!). I've spent far too long trying on this but as the package has no rdeps we should probably just remove it and whoever brings it back can try to understand why it changes behaviour with new libc. (The test also looks a bit fragile, it is asserting that optimizing a particular function with the rng seeded a particular way finds a different maxima to seeding the rng a different way, afaict).

The python-cffi is exposing a bug that exists already. A minimal failing example is this:

root@cosmic32:~# cat n.py 
import math
from cffi.backend_ctypes import CTypesBackend
from cffi import FFI
ffi = FFI(backend=CTypesBackend())
ffi.cdef(""" void fabs(double x); """)
ffi.dlopen('m').fabs(1.0)
print(math.cos(1.23))
root@cosmic32:~# python3 n.py
Traceback (most recent call last):
  File "n.py", line 7, in <module>
    print(math.cos(1.23))
ValueError: math domain error

The bug is that when you lie to cffi about the return type of a variable, in particular when you say a function returning a float does not return a float, the x87 stack is not wiped to the extent required by the calling convention. glibc 2.28 rewrote the cos function in a way that apparently now cares about this (or I guess gcc now compiles the function in a way that cares about this) but make no mistake, it only ever worked by chance before. So I think the test_sin_no_return_value test should be skipped on i386. (I'll file an upstream issue I guess).

Cheers,
mwh

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.28 autopkgtest failures

Michael Hudson-Doyle
On Tue, 4 Sep 2018 at 13:26, Michael Hudson-Doyle <[hidden email]> wrote:
 
The bug is that when you lie to cffi about the return type of a variable, in particular when you say a function returning a float does not return a float, the x87 stack is not wiped to the extent required by the calling convention. glibc 2.28 rewrote the cos function in a way that apparently now cares about this (or I guess gcc now compiles the function in a way that cares about this) but make no mistake, it only ever worked by chance before. So I think the test_sin_no_return_value test should be skipped on i386. (I'll file an upstream issue I guess).

 
Cheers,
mwh

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Reply | Threaded
Open this post in threaded view
|

Re: glibc 2.28 autopkgtest failures

Michael Hudson-Doyle
In reply to this post by Michael Hudson-Doyle
On Tue, 4 Sep 2018 at 13:26, Michael Hudson-Doyle <[hidden email]> wrote:
tl;dr we should force things through :)

There are at the time of writing two autopkgtest failures preventing glibc from migrating: r-cran-rgenoud and python-cffi

The r-cran-genoud failure is mystifying in that I have no idea how the glibc version is affecting the package (it doesn't call many libc or libm functions!). I've spent far too long trying on this but as the package has no rdeps we should probably just remove it and whoever brings it back can try to understand why it changes behaviour with new libc. (The test also looks a bit fragile, it is asserting that optimizing a particular function with the rng seeded a particular way finds a different maxima to seeding the rng a different way, afaict).

The python-cffi is exposing a bug that exists already. A minimal failing example is this:

[...]
 
The bug is that when you lie to cffi about the return type of a variable, in particular when you say a function returning a float does not return a float, the x87 stack is not wiped to the extent required by the calling convention. glibc 2.28 rewrote the cos function in a way that apparently now cares about this (or I guess gcc now compiles the function in a way that cares about this) but make no mistake, it only ever worked by chance before. So I think the test_sin_no_return_value test should be skipped on i386. 

Unfortunately, python-cffi is now failing to build on ppc64el. Code like this (where "source" is a double and target is a valid pointer):

    float r = (float)source;
    memcpy(target, &r, sizeof(float));

is getting compiled into code which doesn't call frsp (round to single precision), which seems very wrong to me. It works if you compile it with gcc-7 or with gcc-8 and no optimization. I've managed to reproduce it like this:

(cosmic-ppc64el)root@diamond:/# cat u.c
#include <math.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

char buf[4];

void write(double x) {
        float y = (float)x;
        memcpy(buf, &y, 4);
}

float read(void) {
        float r;
        memcpy(&r, buf, 4);
        return r;
}

int main(int argc, char**argv) {
        double x;
        x = strtod(argv[1], NULL);
        write(x);
        printf("%g\n", (double)read());
        return 0;
}
(cosmic-ppc64el)root@diamond:/# gcc -fno-inline -O1 -o u u.c
(cosmic-ppc64el)root@diamond:/# ./u 1e200
2.19181e+07

and unless someone can see something wrong in my C code, this looks like a compiler bug :(

Cheers,
mwh

--
ubuntu-devel mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel