[Numpy-discussion] ANN: Numpy 1.6.0 release candidate 1
Christoph Gohlke
cgohlke at uci.edu
Sun May 1 03:19:33 EDT 2011
On 4/30/2011 9:27 PM, Mark Wiebe wrote:
> On Sat, Apr 30, 2011 at 9:11 PM, Christoph Gohlke <cgohlke at uci.edu
> <mailto:cgohlke at 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 at uci.edu
> <mailto:cgohlke at uci.edu>
> > <mailto:cgohlke at uci.edu <mailto:cgohlke at 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 at gmail.com <mailto:charlesr.harris at gmail.com>
> <mailto:charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>>
> > <mailto:charlesr.harris at gmail.com <mailto:charlesr.harris at gmail.com>
> > <mailto:charlesr.harris at gmail.com
> <mailto:charlesr.harris at 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 at scipy.org <mailto:NumPy-Discussion at 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: convert_datatype.diff
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110501/6b3083fc/attachment.ksh>
More information about the NumPy-Discussion
mailing list