On Sun, May 1, 2011 at 12:19 AM, Christoph Gohlke <cgohlke@uci.edu> wrote:
On 4/30/2011 9:27 PM, Mark Wiebe wrote:
On Sat, Apr 30, 2011 at 9:11 PM, Christoph Gohlke <cgohlke@uci.edu <mailto:cgohlke@uci.edu>> wrote:
On 4/30/2011 6:37 PM, Charles R Harris wrote:
On Sat, Apr 30, 2011 at 6:50 PM, Christoph Gohlke <cgohlke@uci.edu
<mailto:cgohlke@uci.edu <mailto:cgohlke@uci.edu>>> wrote:
On 4/30/2011 4:58 PM, Charles R Harris wrote:
On Sat, Apr 30, 2011 at 5:53 PM, Charles R Harris <charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>
<mailto:charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>> <mailto:charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com
<mailto:charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>>>> wrote:
<snip>
I get a null pointer access violation during numpy.test()
with all
msvc9/MKL builds for win32 (not win-amd64). The crash
occurs during
test_result_type() in test_numeric.py and can be reduced
to the
following code:
> import numpy as np > np.result_type(np.array([np.float32(0)]), np.complex128(0))
np.float64(0) and np.float16(0) also crash. Unfortunately
the debug
builds do not crash.
This is new, right?
Does it depend on the optimization level?
Chuck
Yes it's new. The pure msvc9 builds without MKL also crash. The crash disapperars When compiling with /Od (disable optimization) instead of /Ox (maximum optimization; the default for distutils).
So all of np.float16(0), np.float32(0), np.float64(0), etc crash? Does it depend at all on 0 as the argument, or is it the same for 1, 0.0, etc. What about string arguments like np.float64("0"). I want to
<mailto:cgohlke@uci.edu> pin the
location down a bit more. Too bad it doesn't crash in the debugger.
Chuck
Sorry, I should have been more precise. The crash occurs in `numpy.result_type(a, b)` with the following inputs:
b = numpy.complex128(0) a = numpy.array([numpy.float16(0)]) a = numpy.array([numpy.float32(0)]) a = numpy.array([numpy.float64(0)])
Christoph _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org>
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Can you try it with this commit backed out?
https://github.com/numpy/numpy/commit/fc0148bef18b8fd34d124d5edd90887f63e3bf...
What does the stack trace of the crash look like? Compiling with debug information still works with optimizations, just the line numbers and stack traces don't match the source as well.
< https://github.com/numpy/numpy/commit/fc0148bef18b8fd34d124d5edd90887f63e3bf...
-Mark
Sorry, I get no stack trace; apparently the stack is corrupted. I printf-debugged it down to the following preprocessor directive, which already caused trouble in gcc before < http://projects.scipy.org/numpy/ticket/1737>:
#if NPY_SIZEOF_LONGLONG >= NPY_SIZEOF_CLONGDOUBLE npy_longlong value; #else npy_clongdouble value; #endif
Replacing the two occasions of this code in multiarray/convert_datatype.c with `npy_longlong value[4];` solved the crash and all tests pass.
Btw, where is NPY_SIZEOF_CLONGDOUBLE defined? I searched the source code and the build directory but could not find it.
Christoph
I committed that fix. I think NPY_SIZEOF_CLONGDOUBLE isn't actually defined, but it appears the C preprocessor doesn't consider that an error or even a warning, rather an opportunity to provide a surprise for the user of the code. -Mark