On Fri, Feb 23, 2024 at 11:22 AM José Abílio Matos <jamatos(a)fc.up.pt> wrote:
https://koji.fedoraproject.org/koji/taskinfo?taskID=113947607
Most of the errors are like this
E numpy.core._exceptions._ArrayMemoryError: Unable to allocate 320. GiB for an
array with shape (42949672961,) and data type float64
I am surprised with the fact that the s390x builders do not have at least 320 GiB of RAM,
they are clearly under-powered. ;-)
On a more serious, and boring, note does this warning rings a bell to anyone who had a
similar problem?
Yes, many times. :-) This kind of thing happens when a pointer to a
64-bit integer gets passed to something that expects a pointer to a
32-bit integer. In this case, src/rng/rng_helpers.c has a number of
variables named "dimension" that have type PyGSL_array_index_t. That
type has the same size as a pointer; i.e., it is a 32-bit integer on
32-bit systems and a 64-bit integer on 64-bit systems.
At various places in rng_helpers.c, a dimension variable is
initialized to 1, then PyArg_ParseTuple is called to parse an integer
into it. The type code "i" is given. Python thinks that means we
passed it a pointer to a 32-bit integer. On little endian systems,
that's okay as long as the integer to be parsed fits into a 32-bit
integer; we overwrite the 1. On big endian systems, however, we write
the parsed 32-bit integer into the most significant 32 bits of the 64
bit integer, leaving the 1 in the least significant bits. This leaves
the dimension variable holding a value like 42949672961 ==
0xa00000001, when it should have held the value 10. The fix is to pass
"l" into PyArg_ParseTuple instead of "i".
I have added a patch for this to
https://src.fedoraproject.org/rpms/pygsl/pull-request/2, which (gentle
prod here) has now been open for 6 months. If you don't want all of
it, we can eject unwanted commits from the PR.
I'll open a PR upstream for this issue.
Regards,
--
Jerry James
http://www.jamezone.org/