On Tue, Dec 15, 2009 at 9:51 AM, Pauli Virtanen <pav+sp@iki.fi> wrote:
Tue, 15 Dec 2009 10:36:03 -0600, Bruce Southey wrote:
[clip]
> Program received signal SIGSEGV, Segmentation fault. setup_context
> (registry=<value optimized out>, module=<value optimized out>,
> lineno=<value optimized out>, filename=<value optimized out>,
> stack_level=<value optimized out>)
>      at Python/_warnings.c:449
> 449         PyFrameObject *f = PyThreadState_GET()->frame; (gdb) bt
> #0  setup_context (registry=<value optimized out>, module=<value
> optimized out>, lineno=<value optimized out>, filename=<value optimized
> out>, stack_level=<value optimized out>)
>      at Python/_warnings.c:449
> #1  do_warn (registry=<value optimized out>, module=<value optimized
> out>, lineno=<value optimized out>, filename=<value optimized out>,
> stack_level=<value optimized out>)
>      at Python/_warnings.c:593
> #2  0x0000000000493c81 in PyErr_WarnEx (category=0x760720, text=<value
> optimized out>, stack_level=1) at Python/_warnings.c:719 #3
> 0x00000000004c8e94 in PyOS_ascii_strtod (nptr=0x7ffff7f08914 "1 , 2 , 3
> , 4", endptr=0x7fffffffdb28) at Python/pystrtod.c:282 #4
> 0x00007ffff2954151 in NumPyOS_ascii_strtod (s=0x7ffff7f08914 "1 , 2 , 3
> , 4", endptr=0x7fffffffdb28) at numpy/core/src/multiarray/numpyos.c:527

Looks like it's trying to raise a deprecation warning after
PyArray_FromString has released GIL. So that was the reason why it caused
a segfault also in 3.1.

PyOS_ascii_strtod was deprecated in 2.7 and in 3.1. Apparently, we now
*must* do something like

#if PY_VERSION_HEX >= 0x02060000
   return PyOS_string_to_double(s, endptr, NULL);
#else
   return PyOS_ascii_strtod(s, endptr);
#endif

everywhere the function is used.

It also seems that this needs to be backported to Numpy 1.4.x...

(Note to self: this is also the origin of the crashes in scipy/
lambertw... GIL must be reacquired before raising any warnings.)


Would it be appropriate to put macros for all these in config.h or some other common spot? Having all the python version dependencies in one spot might make it easier to keep current. I've been thinking of moving the numpy deprecation macro for that reason.

Chuck