-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
Segfault from using probably invalid dtype #2865
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
Comments
Simpler version of problem:
|
It segfaults for me too:
Oops. We should fix this segfault before the final release. |
I'm not convinced it needs to be fixed immediately. There are always going to be bugs and if you wait to fix all of them you will never release. I think it would be better to wait 1.7.1 or 1.8.. This segfault is also occurrs in numpy 1.5. It makes me thing that there are several spots in numpy where using a standard parser generator and a formal language desciption might be the way to go. It might clarify some of these things and make maintenance easier. I'm thinking dtypes and maybe casting rules. |
Ok, that sounds good to me. In any case, I am now releasing rc1. |
Removing the 1.7 milestone because I agree w/ @charris. We've already shipped this bug, so releasing 1.7 with this bug won't make anything worse for anyone. |
Still present in 1.9-devel. |
I don't really understand the dtype syntax but what is happening is that somewhere during its parsing it loses the NPY_NEEDS_INIT flag of the object dtype so it works on uninitialized memory later. |
BUG: add checks for some invalid structured dtypes. Fixes #2865.
Fixed by #8235 |
On a 64 bit machine this leads to a segfault.
The type on the right should probably be illegal.
The text was updated successfully, but these errors were encountered: