On Sun, May 1, 2011 at 12:19 AM, Christoph Gohlke <cgoh...@uci.edu> wrote:
> > > On 4/30/2011 9:27 PM, Mark Wiebe wrote: > >> On Sat, Apr 30, 2011 at 9:11 PM, Christoph Gohlke <cgoh...@uci.edu >> <mailto:cgoh...@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 <cgoh...@uci.edu >> <mailto:cgoh...@uci.edu> >> > <mailto:cgoh...@uci.edu <mailto:cgoh...@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.har...@gmail.com <mailto:charlesr.har...@gmail.com> >> <mailto:charlesr.har...@gmail.com <mailto:charlesr.har...@gmail.com>> >> > <mailto:charlesr.har...@gmail.com <mailto:charlesr.har...@gmail.com >> > >> > <mailto:charlesr.har...@gmail.com >> <mailto:charlesr.har...@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 >> 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/fc0148bef18b8fd34d124d5edd90887f63e3bfce#L0R1147 >> >> 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/fc0148bef18b8fd34d124d5edd90887f63e3bfce#L0R1147 >> >-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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
