Numpy: BUG: non-numeric kernel_version on the OVH platform

Created on 24 Jun 2020  ·  5Comments  ·  Source: numpy/numpy

Hello, there is an error in the code of __ini__.py (Python3.8) , when detecting the version of the Kernel.
I found the solution but I detail the problem here to help other users.

    # We usually use madvise hugepages support, but on some old kernels it
    # is slow and thus better avoided.
    # Specifically kernel version 4.6 had a bug fix which probably fixed this:
    # https://github.com/torvalds/linux/commit/7cf91a98e607c2f935dbcc177d70011e95b8faff
    import os
    use_hugepage = os.environ.get("NUMPY_MADVISE_HUGEPAGE", None)
    if sys.platform == "linux" and use_hugepage is None:
        use_hugepage = 1
        kernel_version = os.uname().release.split(".")[:2]
        kernel_version = tuple(int(v) for v in kernel_version)
        if kernel_version < (4, 6):
            use_hugepage = 0
    elif use_hugepage is None:
        # This is not Linux, so it should not matter, just enable anyway
        use_hugepage = 1
    else:
        use_hugepage = int(use_hugepage)

    # Note that this will currently only make a difference on Linux
    core.multiarray._set_madvise_hugepage(use_hugepage)

Error message:

# usr\local\lib\python3.8\site-packages\numpy\__init__.py

 #python3.8 test.py
['4', '19-ovh-xxxx-std-ipv6-64']
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    kernel_version = tuple(int(v) for v in kernel_version)
  File "test.py", line 4, in <genexpr>
    kernel_version = tuple(int(v) for v in kernel_version)
ValueError: invalid literal for int() with base 10: '19-ovh-xxxx-std-ipv6-64'

Numpy/Python version information:

To fix this error, here is the solution:

python kernel_version = tuple(int(v[0:2]) for v in kernel_version)

The int (v [0: 2] ) truncate the string to recover the INT correctly.

00 - Bug high

All 5 comments

Hi,

I'm having the same issue with the kernel shipped with OVH.
I see you are making the pull request. Thanks !

Hmmm, my error, why didn't I use looseversion here?

Oh, looking again (sorry missing things a bit more today), that is a strange version string, dropping the micro-release. But, it seems that LooseVersion does handle it correctly, so I think we can just use that here. Although I guess importing distutils may be slow, so maybe just add a try:/except: its not very important to begin with.

I couldnt find the pull request, @nejib1 do you happen to be working on it.

@anirudh2290 There isn't a PR, could you make one? There seem to be two fixes, one given in the report and @seberg use of LooseVersion.

Was this page helpful?
0 / 5 - 0 ratings