Skip to content

BUG: Do not crash on recursive .dtype attribute lookup. #13003

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

Merged
merged 1 commit into from
Jul 3, 2019

Conversation

seberg
Copy link
Member

@seberg seberg commented Feb 20, 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 gh-12982, gh-3614, and gh-12751


Frankly, I am not sure it is actually worth the trouble, but had started on it. The actual error message does not always include the custom message, this seems because the recursion error can also be triggered by the GetAttr call (at least when dtype is made a property).

If we attack dtypes in any case, I am afraid adding more band-aids will just make things harder in the long run anyway.

@seberg seberg force-pushed the dtype-attr-recursion branch 4 times, most recently from fdbab42 to 2aa6521 Compare February 22, 2019 02:14
new->names = conv->names;
Py_INCREF(new->names);
Py_XINCREF(new->names);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a bug fix?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, although it might be that the bug it fixes is in paths that normal code should not reach.

@eric-wieser
Copy link
Member

Generally looks good. Perhaps you should split the deprecation into a separate PR - I think this is close to being ready, but with the deprecation in place it would maybe need to hit the mailing list. Would be a shame to block the bug fix on that.

@seberg
Copy link
Member Author

seberg commented May 16, 2019

Split off the deprecation (and that funny maintanence of the tests) into gh-13578.

@seberg seberg force-pushed the dtype-attr-recursion branch from a80e323 to 929910b Compare May 21, 2019 23:18
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 seberg force-pushed the dtype-attr-recursion branch from 929910b to 65da904 Compare May 26, 2019 04:57
@mattip mattip requested a review from eric-wieser May 31, 2019 13:13
@mattip
Copy link
Member

mattip commented Jun 9, 2019

@eric-wieser any more review comments?

@mattip mattip merged commit 5ce770a into numpy:master Jul 3, 2019
@mattip
Copy link
Member

mattip commented Jul 3, 2019

As an error is better than a segfault, thanks @seberg

@seberg seberg deleted the dtype-attr-recursion branch July 12, 2019 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Passing MagicMock to np.dtype causes a segmentation fault
4 participants