Re: pygsl tests fail on s390x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 23, 2024 at 11:22 AM José Abílio Matos <jamatos@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux