Try building on windows-2022 #294
Conversation
src/flint/types/fmpz.pyx
Outdated
| cdef char * s | ||
| if COEFF_IS_MPZ(x[0]): | ||
| s = fmpz_get_str(NULL, 16, x) | ||
| v = int(str_from_chars(s), 16) | ||
| v = int(bytes(s).decode('ascii'), 16) | ||
| libc.stdlib.free(s) | ||
| return v |
There was a problem hiding this comment.
I'm not sure why this change seems to have fixed the problem. The function is defined as:
cdef inline str_from_chars(s):
return bytes(s).decode('ascii')
However actually inlining the function here prevents the crash that is only seen on Windows when building with windows-2022 or windows-2025 but not if built on windows-2019... (The crash happens when running on any Windows version but not if the binaries were built on windows-2019.)
There was a problem hiding this comment.
No, I was tricked. This change does not fix the problem. I fell for the classic printing things makes the segfault go away confusion.
There was a problem hiding this comment.
Maybe this should use flint_free?
There was a problem hiding this comment.
Or maybe it didn't even work then. I might have looked at the wrong CI output. It is late and there are too many jobs to check...
There was a problem hiding this comment.
Maybe PyLong_FromString should be used:
https://docs.python.org/3/c-api/long.html#c.PyLong_FromString
There was a problem hiding this comment.
It seems that using flint_free fixes this although now there is a crash somewhere else.
There was a problem hiding this comment.
All the observed problems were fixed by using flint_free when using fmpz_get_str. I'm not sure why this issue appears now and not before.
It is probably worth reviewing all other uses of free to see if they should be flint_free...
oscarbenjamin
force-pushed
the
pr_windows_2022_2nd
branch
from
e5b03e4 to
da48c45
Compare
Follows gh-291