8000 Test failures TestNewBufferProtocol.test_error_too_many_dims · Issue #11115 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Test failures TestNewBufferProtocol.test_error_too_many_dims #11115

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
matthew-brett opened this issue May 18, 2018 · 25 comments
Closed

Test failures TestNewBufferProtocol.test_error_too_many_dims #11115

matthew-brett opened this issue May 18, 2018 · 25 comments
Labels
06 - Regression

Comments

@matthew-brett
Copy link
Contributor

See: https://travis-ci.org/MacPython/numpy-wheels/jobs/380655687

________________ TestNewBufferProtocol.test_error_too_many_dims ________________

self = <numpy.core.tests.test_multiarray.TestNewBufferProtocol object at 0xf041f20c>

    def test_error_too_many_dims(self):
        def make_ctype(shape, scalar_type):
            t = scalar_type
            for dim in shape[::-1]:
                t = dim * t
            return t
    
        # construct a memoryview with 33 dimensions
        c_u8_33d = make_ctype((1,)*33, ctypes.c_uint8)
        m = memoryview(c_u8_33d())
        assert_equal(m.ndim, 33)
    
        assert_raises_regex(
            RuntimeError, "ndim",
>           np.array, m)

c_u8_33d   = <class 'numpy.core.tests.test_multiarray.c_ubyte_Array_1_Array_1_Array_1_Array...ay_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1_Array_1__Array_1'>
m          = <memory at 0xf2da0e3c>
make_ctype = <function make_ctype at 0xf041cb1c>
self       = <numpy.core.tests.test_multiarray.TestNewBufferProtocol object at 0xf041f20c>

/venv/local/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py:6534: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <numpy.testing._private.utils._Dummy testMethod=nop>
expected_exception = <type 'exceptions.RuntimeError'>, expected_regexp = 'ndim'
callable_obj = <built-in function array>, args = (<memory at 0xf2da0e3c>,)
kwargs = {}, context = <unittest.case._AssertRaisesContext object at 0xf041ff2c>

    def assertRaisesRegexp(self, expected_exception, expected_regexp,
                           callable_obj=None, *args, **kwargs):
        """Asserts that the message in a raised exception matches a regexp.
    
            Args:
                expected_exception: Exception class expected to be raised.
                expected_regexp: Regexp (re pattern object or string) expected
                        to be found in error message.
                callable_obj: Function to be called.
                args: Extra args.
                kwargs: Extra kwargs.
            """
        context = _AssertRaisesContext(expected_exception, self, expected_regexp)
        if callable_obj is None:
            return context
        with context:
>           callable_obj(*args, **kwargs)
E           ValueError: '(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)<B' is not a valid PEP 3118 buffer format string

args       = (<memory at 0xf2da0e3c>,)
callable_obj = <built-in function array>
context    = <unittest.case._AssertRaisesContext object at 0xf041ff2c>
expected_exception = <type 'exceptions.RuntimeError'>
expected_regexp = 'ndim'
kwargs     = {}
self       = <numpy.testing._private.utils._Dummy testMethod=nop>

Only for 32-bit Unicode Python 2.7: https://travis-ci.org/MacPython/numpy-wheels/builds/380655679

Error present at commit db552b5 "Merge pull request #10996 from adeak/docfix-stringio-unicode" (23 days ago).

Not present at commit b5c1bcf "Merge pull request #10891 from eric-wieser/assert-no-cycles" (25 days ago): https://travis-ci.org/MacPython/numpy-wheels/builds/370054701

In git log b5c1bcf1e..db552b5b6 I noticed references to #10971 and #10882 which both mention buffers - are they relevant?
@charris
Copy link
Member
charris commented May 18, 2018

Hmm, I recall reporting this somewhere. In any case, the failing test came in with #10882, so this may not actually be new. @eric-wieser If you have time, could you take a look?

@charris
Copy link
Member
charris commented May 18, 2018

Yep, also mentioned in #10970 and #10968. Hmm, this problem looks debugable.

@matthew-brett
Copy link
Contributor Author

Dammit - sorry - I thought I'd searched for the test name ...

@charris
Copy link
Member
charris commented May 18, 2018

I wonder if it is a python 2.7 micro version problem. I don't know what version MacPython is running, but maybe we can upgrade it.

@charris
Copy link
Member
charris commented May 18, 2018

I don't see anything in the cpython history of memory views that looks relevant. I'm going to guess that the problem is something else, but still Python 2.7 version related.

@mattip
Copy link
Member
mattip commented May 18, 2018

FWIW, and it probably isn't worth much since memoryview support for ctypes/c-api seems incomplete, PyPy2 is also showing new test failures on NumPy HEAD

@charris
Copy link
Member
charris commented May 18, 2018

Hmm, "ValueError" instead of "RuntimeError", message is also wrong, should be

RuntimeError: PEP3118 dimensions do not satisfy 0 <= ndim <= NPY_MAXDIMS

strange, it looks like the wrong version of numpy is being run.

@eric-wieser
Copy link
Member

Just to complete the linking, there was a comment thread about this at #10970 (comment).

For whatever reason, it seems that on my machine, the PEP3118 parsing succeeds, and then the second pass of actually checking we can use the format fails.

It seems that for those builds, the PEP3118 parsing fails before the ndim check is even reached.

This is very strange, given that I thought that parsing was happening in pure python.

Are we able to reproduce this error on anything other than that build server?

@charris
Copy link
Member
charris commented May 18, 2018

There are some fixes for ctypes that went in last fall, @pv submitted them, but I don't see how they are relevant unless there is a type error being detected before the dimension error.

@charris
Copy link
Member
charris commented May 18, 2018

I haven't seen it anywhere else, and only for the manylinux1 wheel builds.

@charris
Copy link
Member
charris commented May 19, 2018

The easy fix here might be to disable the test for python 2.7. Bit drastic. Or we could just check for an error. rather than a particular error.

@eric-wieser
Copy link
Member
eric-wieser commented May 19, 2018 •
edited
Loading

Would be great to know what the cause is here. I'll submit a PR to chain the exceptions (edit: #11119), but unfortunately that won't help python 2

@eric-wieser
Copy link
Member

Calling _dtype_from_pep3118('(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)<B') in that environment ought to be a sufficient test. Is there any way to run that without actually pushing to master?

@charris
Copy link
Member
charris commented May 19, 2018

Interesting question. Could create a temporary numpy branch with the test and make a PR on numpy-wheels. I don't know if you can make it pull from another repo without more work. @matthew-brett Thoughts?

@matthew-brett
Copy link
Contributor Author

Here's building and running the code in the test environment:

c.f. https://github.com/scikit-image/scikit-image/wiki/Testing-in-32-bit-environment

cd numpy
git pull
git clean -fxd
docker pull matthewbrett/trusty:64
docker run --rm -ti -e PYTHON_VERSION=2.7 -v $PWD:/io matthewbrett/trusty:64 /bin/bash

In the docker test container:

pip install Cython
cd /io
pip install -e .
python -c "from numpy.core._internal import _dtype_from_pep3118; _dtype_from_pep3118('(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)<B')"

giving output:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "numpy/core/_internal.py", line 487, in _dtype_from_pep3118
    dtype, align = __dtype_from_pep3118(stream, is_subdtype=False)
  File "numpy/core/_internal.py", line 592, in __dtype_from_pep3118
    value = dtype((value, shape))
ValueError: invalid shape in fixed-type tuple.

I get the same output if I first build the wheel in the manylinux docker container, then test in the testing container:

git clean -fxd
docker run --rm -ti -e PYTHON_VERSION=2.7 -v $PWD:/io quay.io/pypa/manylinux1_x86_64 /bin/bash

cd /io
pip install cython
export PATH=/opt/python/cp27-cp27mu/bin:$PATH
pip install cython
python setup.py bdist_wheel
auditwheel repair dist/numpy*.whl

docker run --rm -ti -e PYTHON_VERSION=2.7 -v $PWD:/io matthewbrett/trusty:64 /bin/bash

pip install /io/wheelhouse/numpy*manylinux1*.whl 
python -c "from numpy.core._internal import _dtype_from_pep3118; _dtype_from_pep3118('(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)<B')"

@eric-wieser
Copy link
Member

Looks like a ctypes bug. What does the following give in that docker container?

def make_ctype(shape, scalar_type):
    t = scalar_type
    for dim in shape[::-1]:
        t = dim * t
    return t

# construct a memoryview with 33 dimensions
c_u8_33d = make_ctype((1,)*33, ctypes.c_uint8)
m = memoryview(c_u8_33d())

print(m.shape)
print(m.format)

For me I get

(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1)
<B

@matthew-brett
Copy link
Contributor Author 
>>> print(m.shape)
(1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L)
>>> print(m.format)
(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)<B

@eric-wieser
Copy link
Member

Yeah, ctypes is wrong there. What python version?

@matthew-brett
Copy link
Contributor Author

That was Python 2.7.6. I get the same for Python 2.7.5 on Ubuntu 14.04. I get this on Python 2.7.12 on Ubuntu 16.04:

>>> print(m.shape)
(1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L, 1L)
>>> print(m.format)
<B

@eric-wieser
Copy link
Member

I guess we should xfail the test on versions of python. I'll see if I can find the exact version

@eric-wieser
Copy link
Member
eric-wieser commented May 20, 2018 •
edited
Loading

This is https://bugs.python.org/issue10744 (python/cpython@d3d2363)

@mattip
Copy link
Member
mattip commented May 20, 2018

@eric-wieser looking at that issue it seems I should have remembered that, nice detective work

@eric-wieser
Copy link
Member
eric-wieser commented May 20, 2018 •
edited
Loading

Not sure how to find the minor version from that commit. Edit: looked at Include/patchlevel.h - it was Python 2.7.6 that was the last broken version (fixed in 2.7.7)

@mattip, since you've looked at ctype arrays before - could I get you to review python/cpython#5576?

8000

@eric-wieser eric-wieser mentioned this issue May 20, 2018
Merged
@matthew-brett
Copy link
Contributor Author
matthew-brett commented May 20, 2018 via email

@charris
Copy link
Member
charris commented May 23, 2018

Let's just add a skipif decorator to the test and move on. Don't see the use of xfail here, as the test will xpass for later versions of Python 2.7 and the test is just there to check the new error message.

@mattip mattip mentioned this issue May 25, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
06 - Regression
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@matthew-brett @charris @eric-wieser @mattip
0