-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
ENH: skip NPY_ALLOW_C_API for UFUNC_ERR_IGNORE #9985
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
Conversation
GIL unnecessary when numpy floating point error handling is set to ignore.
Is there an bug open for the deadlock? Can you give a reproducer?
…On Nov 7, 2017 19:50, "Ziyan Zhou" ***@***.***> wrote:
GIL unnecessary when numpy floating point error handling is set to ignore.
Fixes an issue where numpy might deadlock when computing a**2 where a is
tiny, e.g. -2.3693744349064819e-197:
#0 0x00007f6ff8c5b536 in do_futex_wait.constprop () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f6ff8c5b5e4 in __new_sem_wait_slow.constprop.0 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f6ff20b6768 in PyThread_acquire_lock (lock=0x55e085e26020, waitflag=<optimized out>) at ../Python/thread_pthread.h:324
#3 0x00007f6ff2028556 in PyEval_RestoreThread (tstate=0x7f6fe11adf40) at ../Python/ceval.c:359
#4 0x00007f6ff20e0b96 in PyGILState_Ensure () at ../Python/pystate.c:611
#5 0x00007f6fcb880dd6 in _error_handler ***@***.***=0, ***@***.***=('double_scalars', None), ***@***.***=0x7f6fcb8d28c1 "underflow", ***@***.***=4, ***@***.***=0x7f6fef64c7b0) at numpy/core/src/umath/ufunc_object.c:119
#6 0x00007f6fcb8872ff in PyUFunc_handlefperr (errmask=521, errobj=('double_scalars', None), ***@***.***=4, ***@***.***=0x7f6fef64c7b0) at numpy/core/src/umath/ufunc_object.c:209
#7 0x00007f6fcb894f08 in double_power (a=<optimized out>, b=2, __NPY_UNUSED_TAGGEDc=<optimized out>) at numpy/core/src/umath/scalarmath.c.src:1168
#8 0x00007f6ff2083a17 in ternary_op.isra.5 (v=<optimized out>, w=<optimized out>, z=None, op_slot=48) at ../Objects/abstract.c:1065
#9 0x00007f6ff2029e0a in PyEval_EvalFrameEx
P.S. the stack is coming from numpy 1.11, but same problem seems to exist
on master.
------------------------------
You can view, comment on, or merge this pull request online at:
#9985
Commit Summary
- ENH skip NPY_ALLOW_C_API for UFUNC_ERR_IGNORE
File Changes
- *M* numpy/core/src/umath/extobj.c
<https://github.com/numpy/numpy/pull/9985/files#diff-0> (5)
Patch Links:
- https://github.com/numpy/numpy/pull/9985.patch
- https://github.com/numpy/numpy/pull/9985.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#9985>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAlOaFT5hX2nuTgmZu3Kbkm5ceDJ-BKsks5s0QjkgaJpZM4QVul6>
.
|
There is no bug open, because I have not found a way to reproduce the deadlock with simple script. I will get back to you on that. |
I added a simple reproduction in this repository: You will need docker to reproduce it. But it is a simple apache2 wsgi running a simple python script |
Diff looks fine, but if there's a deadlock here, can't we still hit it in the other modes anyway? This doesn't seem to solve the underlying problem to me. |
You are right. It does not. I think the deadlock is an instance of gh-8559. And the conclusion there is that wsgi under default settings is not supported by numpy because it uses multiple sub interpreters. I tried |
Sounds pretty convincing to me. The patch looks uncontroversial, so I'll put it in. Thanks! |
Yeah, this sure looks like gh-5856 to me |
Thank you for the quick response! |
Does this PR fix the deadlock in the following simple program ?
|
I've just compiled numpy@master locally and can verify that the above program does not hang anymore. 👍 Do we want to add a stripped down version of the above program to the numpy unit tests? @eric-wieser |
GIL unnecessary when numpy floating point error handling is set to ignore.
Fixes an issue where numpy might deadlock when computing
a**2
wherea
is tiny, e.g.-2.3693744349064819e-197
:P.S. the stack is coming from numpy 1.11, but same problem seems to exist on master.