Skip to content
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.

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

object with 'dtype' property crashes numpy #3614

Closed
mwiebe opened this issue Aug 13, 2013 · 5 comments
Closed

object with 'dtype' property crashes numpy #3614

mwiebe opened this issue Aug 13, 2013 · 5 comments

Comments

@mwiebe
Copy link
Member

mwiebe commented Aug 13, 2013

The following code crashes numpy (latest master):

import numpy as np
class crashnumpy(object):
    @property
    def dtype(self):
        return self
np.array([1], dtype=crashnumpy())
@njsmith
Copy link
Member

njsmith commented Aug 15, 2013

I guess this is triggering an infinite recursion in C code?

In principle we can fix such things, but it takes a bunch of work on a
case-by-case basis, and people who set out to break things have many many
other options using numpy. (We provide free access to arbitrary memory
locations, after all.) Is there some reason this bug is a problem, or is it
just a curiosity?

On Tue, Aug 13, 2013 at 11:36 PM, Mark notifications@github.com wrote:

The following code crashes numpy (latest master):

import numpy as np
class crashnumpy(object):
@Property
def dtype(self):
return self
np.array([1], dtype=crashnumpy())


Reply to this email directly or view it on GitHubhttps://github.com//issues/3614
.

@mwiebe
Copy link
Member Author

mwiebe commented Aug 16, 2013

This came up when I accidentally passed a dynd type to numpy. The dynd type includes dimensions, and its dtype attribute returns the type with these dimensions stripped away. If the type has no dimensions, then it returns itself, leading to a behavior similar to the crashnumpy class.

@OmerJog
Copy link

OmerJog commented Mar 4, 2019

was this fixed?

@seberg
Copy link
Member

seberg commented Mar 4, 2019

No, gh-13003 includes this fix, but I was travelling and on a small conference now, so I did not finish it up. I guess we will probably have it fixed soon. Does this affect you much?

seberg added a commit to seberg/numpy that referenced this issue May 26, 2019
The code path in scalarapi.c which checks dtype on one inheriting
from np.void is especially awkward and was completely untested
previously. So I am not sure we should even support it at all.

Closes numpygh-12982, numpygh-3614, and numpygh-12751
charris pushed a commit to charris/numpy that referenced this issue Jul 14, 2019
The code path in scalarapi.c which checks dtype on one inheriting
from np.void is especially awkward and was completely untested
previously. So I am not sure we should even support it at all.

Closes numpygh-12982, numpygh-3614, and numpygh-12751
charris pushed a commit to charris/numpy that referenced this issue Jul 14, 2019
The code path in scalarapi.c which checks dtype on one inheriting
from np.void is especially awkward and was completely untested
previously. So I am not sure we should even support it at all.

Closes numpygh-12982, numpygh-3614, and numpygh-12751
@seberg
Copy link
Member

seberg commented Sep 22, 2019

Oh, forgot to close this one. It raises a maximum recursion depth error right now. There is the next step of deprecating parts of it, but there was even another issue about it IIRC.

@seberg seberg closed this as completed Sep 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants