ENH: skip NPY_ALLOW_C_API for UFUNC_ERR_IGNORE#9985
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**2whereais tiny, e.g.-2.3693744349064819e-197:P.S. the stack is coming from numpy 1.11, but same problem seems to exist on master.