Wrong float4 struct pack on ppc64le and musl-based linux. #92826
Labels
type-bug
An unexpected behavior, bug, or error
Comments
|
What does |
And the reason for asking: if the above is not returning "unknown", then this is the relevant code for converting a Lines 2263 to 2282 in 9d38120 If you have the facilities to debug on the target machine, that would be the starting point to look at. I'd want to double-check that |
|
One more question: after |
dvarrazzo
added a commit
to psycopg/psycopg
that referenced
this issue
May 26, 2022
|
Requested info at https://github.com/psycopg/psycopg/runs/6607562276?check_suite_focus=true#step:6:437: |
|
Thanks. The first is what I was expecting (or at least hoping for). That second result is interesting - I was expecting to at least see a subset of the bytes of either the original double value or the converted float. Staring at the code, I'm having a hard time seeing what could be wrong. Is it possible that there's a compiler or libc bug? Are you in a position to test with a version of Python compiled without the |
|
@tiran Do I recall correctly that you have some familiarity with musl-based Linux distros? If so, any ideas what might be going wrong here? |
|
I'm neither an Alpine expert nor a heavy user of Alpine Linux. All I did was founding a couple of problems with musl libc implementation. By the way, Alpine is still an unsupported platform. Python upstream does not support it because it has known bugs and we lack a stable build bot. Anyhow I can reproduce the issue with Alpine container image, podman, and qemu-static: The same code works on emulated PPC64 LE Fedora: |
|
It looks like a compiler or libc bug on Alpine: #include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char **argv) {
double d = atof(argv[1]);
printf("%f\n", d);
float y = (float)d;
unsigned char s[sizeof(float)];
memcpy(s, &y, sizeof(float));
printf("%02x%02x%02x%02x\n", s[3], s[2], s[1], s[0]);
return 0;
} |
|
Many thanks, @tiran. Looks like there's not a lot CPython can or should do here, then. @dvarrazzo Okay to close here? (It may be worth copying @tiran's reproducer to the Alpine bug report, though.) |
|
@mdickinson that's ok for me, thank you for helping to restrict the cause of the problem. Yes, I will update Alpine folks about the developments here. As far as psycopg is concerned, we are ok: we have a way to detect the issue and a workaround. Maybe you can incentivize Alpine linux to provide a solution by adding a failing test in the CPython test suite? |
Yes, we should definitely have a test; I'd be a bit surprised (and disturbed) if we're not exercising this code in the existing test suite. I'll check. |
Python's struct tests are failing on Alpine PPC64LE. This starts to look like a QA problem on Alpine's side. We really need some engineers from Alpine and musl to address the musl libc bugs from #90548 and then stable buildbots that run Python builds + tests on platforms supported by Alpine. |
|
Thanks again, @tiran. And I've double checked that that part of the code is indeed well exercised by the test suite. Closing here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Normally:
struct.Struct('!f').pack(1.0).hex()=3f800000On musllinux ppc64le,
struct.Struct('!f').pack(1.0).hex()=00000000Example working manylinux run
Example broken musllinux run
The architecture is the same for both the runs. Reproducible on Python 3.6-3.10.
See psycopg/psycopg#304
Reported to the Alpine project at https://gitlab.alpinelinux.org/alpine/aports/-/issues/13811
The text was updated successfully, but these errors were encountered: