I am not observing this with Canopy on MacOS 10.8.5 (64bit). I have numpy
1.8.0 and cPickle 1.71.
My guess is that it is a problem with your setup. To figure out what is
going on, I would have more questions for you so please email me privately
a good email address to reach you at.
Best,
Hi,
Since I've updated numpy from 1.7 to 1.8 with EPD I get segmentation faults
whenever I load back pickled float64 arrays. Here's a minimal example:
import numpy
import cPickle
a = numpy.arange(5, dtype='float64')
with open('test.p', 'wb') as fh:
cPickle.dump(a, fh)
with
On Sat, Dec 21, 2013 at 2:16 PM, Hugo Gagnon
opensource.nu...@user.fastmail.fm wrote:
Hi,
Since I've updated numpy from 1.7 to 1.8 with EPD I get segmentation
faults whenever I load back pickled float64 arrays. Here's a minimal
example:
import numpy
import cPickle
a =
Mac OS 10.8.5
--
Hugo Gagnon
On 2013-12-21, at 5:20 PM, Charles R Harris charlesr.har...@gmail.com wrote:
On Sat, Dec 21, 2013 at 2:16 PM, Hugo Gagnon
opensource.nu...@user.fastmail.fm wrote:
Hi,
Since I've updated numpy from 1.7 to 1.8 with EPD I get segmentation faults
Charles R Harris charlesr.harris at gmail.com writes:
On Thu, Apr 12, 2012 at 8:13 PM, Charles R Harris charlesr.harris at
gmail.com wrote:
On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris charlesr.harris at
gmail.com wrote:
On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceball at
On Mon, Apr 16, 2012 at 5:16 PM, Chris Ball ceb...@gmail.com wrote:
Charles R Harris charlesr.harris at gmail.com writes:
On Thu, Apr 12, 2012 at 8:13 PM, Charles R Harris charlesr.harris at
gmail.com wrote:
On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris charlesr.harris at
On 4/12/12 8:41 PM, Charles R Harris wrote:
It seems that python2.7 is far, far, too recent to be part of Debian
6. I mean, finding python 2.7 in recent Debian stable would be like
finding an atomic cannon in a 1'st dynasty Egyptian tomb. So it is in
testing, but for replication I like to know
On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote:
Hi,
I'm trying out various continuous integration options, so I happen to be
testing NumPy on several platforms that I don't normally use.
Recently, I've been getting a segmentation fault on Debian 6 (with Python
2.7.2):
On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote:
Hi,
I'm trying out various continuous integration options, so I happen to be
testing NumPy on several platforms that I don't normally use.
Recently, I've been getting a segmentation fault on Debian 6 (with Python
2.7.2):
On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote:
Hi,
I'm trying out various continuous integration options, so I happen to be
testing NumPy on several platforms that I don't normally
On Thu, Apr 12, 2012 at 8:13 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Thu, Apr 12, 2012 at 7:41 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Thu, Apr 12, 2012 at 2:05 AM, Chris Ball ceb...@gmail.com wrote:
Hi,
I'm trying out various continuous integration
Hi All,
I installed numpy from the scipy superpack on Snow Leopard with python 2.7
and it all appears to work but when I do the following, I get a segmentation
fault.
import numpy
print numpy.__version__, numpy.__file__
2.0.0.dev-b5cdaee
It's a wild guess, but in the past I've had seg faults issues on Mac due to
conflicting versions of Python. Do you have multiple Python installs on your
Mac?
-=- Olivier
2011/8/2 Thomas Markovich thomasmarkov...@gmail.com
Hi All,
I installed numpy from the scipy superpack on Snow Leopard
I just have the default apple version of python that comes with Snow
Leopard (Python 2.6.1 (r261:67515, Aug 2 2010, 20:10:18)) and python 2.7
(Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) ) installed.
Should I just remove 2.7 and reinstall everything with the standard apple
python?
On 08/02/2011 11:14 AM, Thomas Markovich wrote:
I just have the default apple version of python that comes with Snow
Leopard (Python 2.6.1 (r261:67515, Aug 2 2010, 20:10:18)) and python
2.7 (Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) )
installed.
Should I just remove 2.7 and
On Tue, Aug 2, 2011 at 6:14 PM, Thomas Markovich
thomasmarkov...@gmail.comwrote:
I just have the default apple version of python that comes with Snow
Leopard (Python 2.6.1 (r261:67515, Aug 2 2010, 20:10:18)) and python 2.7
(Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) )
It appears that uninstalling python 2.7 and installing the scipy superpack
with the apple standard python removes the segfaulting behavior from numpy.
Now it appears that just scipy is segfaulting at test
test_arpack.test_hermitian_modes(True, std-hermitian, 'F', 2, 'SM', None,
0.5, function
On Tue, Aug 2, 2011 at 6:57 PM, Thomas Markovich
thomasmarkov...@gmail.comwrote:
It appears that uninstalling python 2.7 and installing the scipy superpack
with the apple standard python removes the segfaulting behavior from numpy.
Now it appears that just scipy is segfaulting at test
On 2 Aug 2011, at 18:57, Thomas Markovich wrote:
It appears that uninstalling python 2.7 and installing the scipy
superpack with the apple standard python removes the
Did the superpack installer automatically install numpy to the
python2.7 directory when present? Even if so, I reckon you
Oh okay, that's unfortunate but I guess not unexpected. Regardless, thank
you so much for all your help Ralf, Bruce, and Oliver! You guys are great.
Just to recap, the issue appears to stem from using the scipy superpack with
python 2.7 from python.org. This was solved by using the apple python
Maybe specify which scipy superpack. Your issue was probably because the
superpack you installed was not meant to be used with Python 2.7.
-=- Olivier
2011/8/2 Thomas Markovich thomasmarkov...@gmail.com
Oh okay, that's unfortunate but I guess not unexpected. Regardless, thank
you so much for
On 8/2/11 10:14 AM, Thomas Markovich wrote:
Just to recap, the issue appears to stem from using the scipy superpack
with python 2.7 from python.org http://python.org. This was solved by
using the apple python along with the scipy superpack.
This sure sounds like a bug in the sciy superpack
On Sat, Jul 24, 2010 at 8:38 PM, David Cournapeau wrote:
In general, because the packaging/build infrastructure in python is horrible.
However, in this precise case, the issue is simply that numpy 1.4.1
does not support python2.7.
How about a tiny update to the numpy 1.4.x on PyPi which
On Fri, Jul 23, 2010 at 11:46 AM, celil celil...@gmail.com wrote:
Hello,
I just installed numpy on Snow Leopard using pip. However, running the
tests results in a segmentation fault. Has anybody else encountered this
problem? How did you solve it?
Do not use pip or easy_install, these
On Sat, Jul 24, 2010 at 1:44 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
On Fri, Jul 23, 2010 at 11:46 AM, celil celil...@gmail.com wrote:
Hello,
I just installed numpy on Snow Leopard using pip. However, running the
tests results in a segmentation fault. Has anybody else
On Sat, Jul 24, 2010 at 2:38 PM, David Cournapeau courn...@gmail.comwrote:
On Sun, Jul 25, 2010 at 3:39 AM, Benjamin Root ben.r...@ou.edu wrote:
I have to wonder why this question keeps coming up.
In general, because the packaging/build infrastructure in python is
horrible.
However, in
On Sun, Jul 25, 2010 at 6:21 AM, Benjamin Root ben.r...@ou.edu wrote:
On Sat, Jul 24, 2010 at 2:38 PM, David Cournapeau courn...@gmail.com
wrote:
On Sun, Jul 25, 2010 at 3:39 AM, Benjamin Root ben.r...@ou.edu wrote:
I have to wonder why this question keeps coming up.
In general, because
On Jul 24, 2010, at 11:39 AM, Benjamin Root wrote:
I have to wonder why this question keeps coming up. Do we need to make the
build/installation instructions on the website clearer?
Yes. I was one who asked recently. I've not seen easy_install nor pip
mentioned on the website nor
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Segmentation fault
The expected result:
AttributeError: 'np.int64' object has no attribute 'argsort'
___
On Fri, Dec 18, 2009 at 11:46, Keith Goodman kwgood...@gmail.com wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Segmentation fault
The expected result:
AttributeError: 'np.int64' object has no
On Fri, Dec 18, 2009 at 12:52 PM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Dec 18, 2009 at 11:46, Keith Goodman kwgood...@gmail.com wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Segmentation
On Fri, Dec 18, 2009 at 11:57, Skipper Seabold jsseab...@gmail.com wrote:
On Fri, Dec 18, 2009 at 12:52 PM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Dec 18, 2009 at 11:46, Keith Goodman kwgood...@gmail.com wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known,
On Fri, Dec 18, 2009 at 9:52 AM, Robert Kern robert.k...@gmail.com wrote:
On Fri, Dec 18, 2009 at 11:46, Keith Goodman kwgood...@gmail.com wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Segmentation
On Fri, Dec 18, 2009 at 10:57 AM, Skipper Seabold jsseab...@gmail.comwrote:
On Fri, Dec 18, 2009 at 12:52 PM, Robert Kern robert.k...@gmail.com
wrote:
On Fri, Dec 18, 2009 at 11:46, Keith Goodman kwgood...@gmail.com
wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
On Fri, Dec 18, 2009 at 1:01 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Dec 18, 2009 at 10:57 AM, Skipper Seabold jsseab...@gmail.com
wrote:
On Fri, Dec 18, 2009 at 12:52 PM, Robert Kern robert.k...@gmail.com
wrote:
On Fri, Dec 18, 2009 at 11:46, Keith Goodman
On Fri, Dec 18, 2009 at 1:00 PM, Robert Kern robert.k...@gmail.com wrote:
Can you give us a gdb backtrace?
No idea what I'm doing, but I figure I should learn a bit... Does
this look right?
skip...@linux-desktop:~$ gdb python
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software
On Fri, Dec 18, 2009 at 1:07 PM, Skipper Seabold jsseab...@gmail.com wrote:
On Fri, Dec 18, 2009 at 1:00 PM, Robert Kern robert.k...@gmail.com wrote:
Can you give us a gdb backtrace?
No idea what I'm doing, but I figure I should learn a bit... Does
this look right?
On Fri, Dec 18, 2009 at 10:46 AM, Keith Goodman kwgood...@gmail.com wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Segmentation fault
The expected result:
AttributeError: 'np.int64' object has no
On 12/18/2009 9:46 AM, Keith Goodman wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Segmentation fault
The expected result:
AttributeError: 'np.int64' object has no attribute 'argsort'
On Windows
On Fri, Dec 18, 2009 at 10:46 AM, Keith Goodman kwgood...@gmail.com wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Segmentation fault
The immediate problem is in scalartypes.c.src in these lines
On Fri, Dec 18, 2009 at 1:02 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Dec 18, 2009 at 10:46 AM, Keith Goodman kwgood...@gmail.com wrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
On Fri, Dec 18, 2009 at 2:02 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Fri, Dec 18, 2009 at 10:46 AM, Keith Goodman kwgood...@gmail.comwrote:
I am using the numpy 1.3 binary from Ubuntu 9.10. Is this already
known, fixed, reproducible?
np.array(121).argsort(0).argsort(0)
Hello,
I've come across what is probably a bug in size check for large arrays:
import numpy
z1 = numpy.zeros((255*256,256*256))
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: dimensions too large.
z2 = numpy.zeros((256*256,256*256))
z2.shape
(65536, 65536)
On Tue, May 26, 2009 at 1:55 AM, Nicolas Rougier
nicolas.roug...@loria.frwrote:
Hello,
I've come across what is probably a bug in size check for large arrays:
import numpy
z1 = numpy.zeros((255*256,256*256))
Traceback (most recent call last):
File stdin, line 1, in module
ValueError:
Does anyone else get this seg fault?
def fn():
x = np.random.rand(5,2)
x.cumsum(None, out=x)
return x
:
fn()
*** glibc detected *** /usr/bin/python: double free or corruption
(out): 0x08212dc8 ***
I'm running 1.0.4 from Debian Lenny with python 2.5.2 compiled with
gcc
On 28 May 2008, at 16:30, Keith Goodman wrote:
Does anyone else get this seg fault?
def fn():
x = np.random.rand(5,2)
x.cumsum(None, out=x)
return x
:
fn()
*** glibc detected *** /usr/bin/python: double free or corruption
(out): 0x08212dc8 ***
I'm running 1.0.4 from
2008/5/28 Keith Goodman [EMAIL PROTECTED]:
Does anyone else get this seg fault?
def fn():
x = np.random.rand(5,2)
x.cumsum(None, out=x)
return x
:
fn()
*** glibc detected *** /usr/bin/python: double free or corruption
(out): 0x08212dc8 ***
I'm running 1.0.4 from Debian
Hmmm. Interesting. I'm on a 64-bit Debian Unstable system with numpy
1.0.4 and python 2.5.2 and I don't get this:
In [1]: import numpy as np
In [2]: np.__version__
Out[2]: '1.0.4'
In [3]: def fn():
...: x = np.random.rand(5,2)
...: x.cumsum(None, out=x)
...: return x
On Wednesday 28 May 2008 10:51:20 am Alan McIntyre wrote:
On Wed, May 28, 2008 at 10:30 AM, Keith Goodman [EMAIL PROTECTED]
wrote:
Does anyone else get this seg fault?
def fn():
x = np.random.rand(5,2)
x.cumsum(None, out=x)
return x
:
fn()
*** glibc
On Wed, 28 May 2008 11:07:16 -0400
Scott Ransom [EMAIL PROTECTED] wrote:
On Wednesday 28 May 2008 10:51:20 am Alan McIntyre
wrote:
On Wed, May 28, 2008 at 10:30 AM, Keith Goodman
[EMAIL PROTECTED]
wrote:
Does anyone else get this seg fault?
def fn():
x = np.random.rand(5,2)
On Wed, May 28, 2008 at 7:30 AM, Keith Goodman [EMAIL PROTECTED] wrote:
Does anyone else get this seg fault?
def fn():
x = np.random.rand(5,2)
x.cumsum(None, out=x)
return x
:
fn()
*** glibc detected *** /usr/bin/python: double free or corruption
(out): 0x08212dc8 ***
I
ke, 2008-05-28 kello 10:59 -0400, Scott Ransom kirjoitti:
Hmmm. Interesting. I'm on a 64-bit Debian Unstable system with numpy
1.0.4 and python 2.5.2 and I don't get this:
In [1]: import numpy as np
In [2]: np.__version__
Out[2]: '1.0.4'
In [3]: def fn():
...: x =
In my experience tracking down these sorts of things, if the effect is
delayed and detected by glibc, it almost always means that a few bytes
beyond the end of the data part of an array have been overwritten.
This causes glibc's memory management stuff to crash later on when the
object is
2008/5/28 Hoyt Koepke [EMAIL PROTECTED]:
In my experience tracking down these sorts of things, if the effect is
delayed and detected by glibc, it almost always means that a few bytes
beyond the end of the data part of an array have been overwritten.
This causes glibc's memory management stuff
On Wed, May 28, 2008 at 10:39 AM, Stéfan van der Walt [EMAIL PROTECTED]
wrote:
2008/5/28 Hoyt Koepke [EMAIL PROTECTED]:
In my experience tracking down these sorts of things, if the effect is
delayed and detected by glibc, it almost always means that a few bytes
beyond the end of the data
2008/5/28 Charles R Harris [EMAIL PROTECTED]:
It's shape related.
In [7]: x = numpy.random.rand(5,2)
In [8]: y = ones((5,2))
In [9]: x.cumsum(None,out=y)
Out[9]:
array([[ 0.76943981, 1.],
[ 1.12678411, 1.],
[ 1.69498328, 1.],
[
2008/5/28 Stéfan van der Walt [EMAIL PROTECTED]:
2008/5/28 Charles R Harris [EMAIL PROTECTED]:
It's shape related.
In [7]: x = numpy.random.rand(5,2)
In [8]: y = ones((5,2))
In [9]: x.cumsum(None,out=y)
Out[9]:
array([[ 0.76943981, 1.],
[ 1.12678411, 1.],
On Wed, May 28, 2008 at 11:22 AM, Stéfan van der Walt [EMAIL PROTECTED]
wrote:
2008/5/28 Charles R Harris [EMAIL PROTECTED]:
It's shape related.
In [7]: x = numpy.random.rand(5,2)
In [8]: y = ones((5,2))
In [9]: x.cumsum(None,out=y)
Out[9]:
array([[ 0.76943981, 1.],
On Wed, May 28, 2008 at 1:37 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I think the bug is not raising an error on shape mismatch, the assumption on
the first index follows from that. For the out=x parameter, I propose the
rules:
1) x must have the shape of the expected output (1D in this
On Wed, May 28, 2008 at 1:17 PM, Alan McIntyre [EMAIL PROTECTED]
wrote:
On Wed, May 28, 2008 at 1:37 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I think the bug is not raising an error on shape mismatch, the assumption
on
the first index follows from that. For the out=x parameter, I
On Wed, May 28, 2008 at 1:06 PM, Alan McIntyre [EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 3:34 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I wonder if this is something that ought to be looked at for all
functions with an out parameter? ndarray.compress also had problems
with array
On Wed, May 28, 2008 at 1:16 PM, Keith Goodman [EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 1:06 PM, Alan McIntyre [EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 3:34 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I wonder if this is something that ought to be looked at for all
functions
Hi Alan
2008/5/28 Alan McIntyre [EMAIL PROTECTED]:
On Wed, May 28, 2008 at 4:19 PM, Stéfan van der Walt [EMAIL PROTECTED]
wrote:
A reminder: if docstrings need to be updated, it is really easy to do:
http://sd-2116.dedibox.fr/doc/Docstrings/
Pauli has been hard at work at writing a Django
On Wed, May 28, 2008 at 5:10 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
Yes, we have mechanisms in place to do that. I haven't merged for a
while, because I am hoping that we can move the docstrings over to the
new (web application) system soon. If that doesn't happen, I will
probably
Hi,
The array I was using is indeed from a pickle. I ran the c example, and got
the following:
$ LD_PRELOAD=/usr/lib/sse2/libcblas.so.3.0 ./sse2-crash-test
good_align: ok
bad_align: Segmentation fault (core dumped)
$ LD_PRELOAD=/usr/lib/libcblas.so.3.0 ./sse2-crash-test
good_align: ok
bad_align:
Hello,
I encountered the error Segmentation fault (core dumped) during a rather
standard multiplication, without excessive memory us. This looks likes a
bug to me?
I am using Python 2.5, Numpy 1.0.4 under Ubuntu 7.10.
Here is what I am doing: i have two arrays, points1 and points2.
ti, 2008-05-06 kello 14:15 +0200, Marius Nijhuis kirjoitti:
Hello,
I encountered the error Segmentation fault (core dumped) during a
rather standard multiplication, without excessive memory us. This
looks likes a bug to me?
I am using Python 2.5, Numpy 1.0.4 under Ubuntu 7.10.
Here is
Hello !
I'm a new user of Numpy. I want to use it to work with matrices (very
huge matrices), select column, make product, etc ...
Configuration : Debian, python 2.4.4 and numpy 1.0.1
So here is my problem:
I initialize a matrix which will contain only 0 and 1
from numpy import *
matCons =
David Cournapeau wrote:
Unless you are executing this on a gigantic computer, this won't work
very well: you are asking to create an array which has ~ 2e5^2 elements,
that is around 40 Gb.
There is a bug, but the bug happens at the above line: the zeros call
did not fail whereas it
Hi all,
Is this a known issue with latest svn
numpy.test(verbosity=2) segfaults with
check_float_repr
(numpy.core.tests.test_scalarmath.TestRepr)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182894186368 (LWP 6930)]
0x003390e3d5e5 in __mpn_mul_1 () from
70 matches
Mail list logo
