On Fri, Feb 23, 2024 at 11:22 AM José Abílio Matos <jama...@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/ -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
