scipy.test errors (generic ld filter, loadmat case callnest)
Hi, I'm running scipy 0.8.5 and numpy 1.0b5 built from source using Debian's stable environment (gcc 3.3, Python 2.3.5) on an AMD64 machine. numpy.test() runs fine, but scipy.test does not. Here are the errors: ====================================================================== ERROR: generic 1d filter 1 ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/williams/usr/lib/python2.3/site-packages/scipy/ndimage/tests/test_ndimage.py", line 1141, in test_generic_filter1d01 extra_keywords = {'total': weights.sum()}) File "/home/williams/usr//lib/python2.3/site-packages/scipy/ndimage/filters.py", line 632, in generic_filter1d mode, cval, origin, extra_arguments, extra_keywords) MemoryError ====================================================================== ERROR: check loadmat case cellnest ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/williams/usr/lib/python2.3/site-packages/scipy/io/tests/test_mio.py", line 80, in cc self._check_case(name, expected) File "/home/williams/usr/lib/python2.3/site-packages/scipy/io/tests/test_mio.py", line 75, in _check_case self._check_level(k_label, expected, matdict[k]) File "/home/williams/usr/lib/python2.3/site-packages/scipy/io/tests/test_mio.py", line 33, in _check_level self._check_level(level_label, ev, actual[i]) File "/home/williams/usr/lib/python2.3/site-packages/scipy/io/tests/test_mio.py", line 30, in _check_level assert len(expected) == len(actual), "Different list lengths at %s" % label TypeError: len() of unsized object ---------------------------------------------------------------------- Ran 1569 tests in 2.105s FAILED (errors=2) I would be very grateful for any suggestions? Indeed, should I even worry about this? Thanks, -- Michael Williams Theoretical Physics, University of Oxford
On Thu, Sep 14, 2006 at 03:55:38PM +0100, Michael Williams wrote:
====================================================================== ERROR: check loadmat case cellnest ----------------------------------------------------------------------
I see this particular error on AMD64 is under discussion elsewhere on the list: http://thread.gmane.org/gmane.comp.python.scientific.user/8768/focus=8772. If this is the same problem, sorry for the list noise! I'm still interested in solving the ld filter error though! Cheers, -- Michael Williams Theoretical Physics, University of Oxford
On Thu, Sep 14, 2006 at 03:55:38PM +0100, Michael Williams wrote:
Hi,
I'm running scipy 0.8.5 and numpy 1.0b5 built from source using Debian's stable environment (gcc 3.3, Python 2.3.5) on an AMD64 machine. numpy.test() runs fine, but scipy.test does not. Here are the errors:
I tried 'from __future__ import scipy' but I can't import v0.8.5 or 0.5.8 :) Is this the latest SVN version (today's)? I committed some changes to the mio code this morning, which may have fixed the cellnest error. Rehards Stéfan
On Thu, Sep 14, 2006 at 05:16:47PM +0200, Stefan van der Walt wrote:
I tried 'from __future__ import scipy' but I can't import v0.8.5 or 0.5.8 :)
I have no idea where I got that version number from! It's been a long day. In fact I was running the 0.5.1 release.
Is this the latest SVN version (today's)? I committed some changes to the mio code this morning, which may have fixed the cellnest error.
I just checked out and built numpy and scipy from source (1.0rc1.dev3154 and 0.5.2.dev2198 respectively), and the cellnest error is gone. Thanks very much! (The ld filter error remains, but has been discussed elsewhere.) Cheers, -- Mike
On Thu, 14 Sep 2006 17:16:10 +0100 Michael Williams <williams@astro.ox.ac.uk> wrote:
On Thu, Sep 14, 2006 at 05:16:47PM +0200, Stefan van der Walt wrote:
I tried 'from __future__ import scipy' but I can't import v0.8.5 or 0.5.8 :)
I have no idea where I got that version number from! It's been a long day. In fact I was running the 0.5.1 release.
Is this the latest SVN version (today's)? I committed some changes to the mio code this morning, which may have fixed the cellnest error.
I just checked out and built numpy and scipy from source (1.0rc1.dev3154 and 0.5.2.dev2198 respectively), and the cellnest error is gone. Thanks very much!
But a new bug is introduced in latest svn ... See http://projects.scipy.org/scipy/scipy/ticket/263 Nils
(The ld filter error remains, but has been discussed elsewhere.)
I cannot reproduce that error...
Cheers, -- Mike _______________________________________________ SciPy-user mailing list SciPy-user@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-user
On Thu, Sep 14, 2006 at 07:31:19PM +0200, Nils Wagner wrote:
On Thu, 14 Sep 2006 17:16:10 +0100 Michael Williams <williams@astro.ox.ac.uk> wrote:
On Thu, Sep 14, 2006 at 05:16:47PM +0200, Stefan van der Walt wrote:
I tried 'from __future__ import scipy' but I can't import v0.8.5 or 0.5.8 :)
I have no idea where I got that version number from! It's been a long day. In fact I was running the 0.5.1 release.
Is this the latest SVN version (today's)? I committed some changes to the mio code this morning, which may have fixed the cellnest error.
I just checked out and built numpy and scipy from source (1.0rc1.dev3154 and 0.5.2.dev2198 respectively), and the cellnest error is gone. Thanks very much!
But a new bug is introduced in latest svn ... See
Are you sure that this is a bug? Please give feedback as requested in the ticket comment. Regards Stéfan
Hi,
(The ld filter error remains, but has been discussed elsewhere.)
I am getting that error too on an x86_64 machine. Has it in fact been discussed elsewhere? I think the thread you pointed to was just the error report wasn't it? Matthew
Hi,
(The ld filter error remains, but has been discussed elsewhere.)
I am getting that error too on an x86_64 machine. Has it in fact been discussed elsewhere? I think the thread you pointed to was just the error report wasn't it?
Actually I've appended a test script that reproduces it; the first call to ndimage.generic_filter1d works, but the second (in my script: identical) call generates a memory error, only on my x86_64 machine: import numpy as N import scipy.ndimage as ndimage def _filter_func(input, output, fltr, total): fltr = fltr / total for ii in range(input.shape[0] - 2): output[ii] = input[ii] * fltr[0] output[ii] += input[ii + 1] * fltr[1] output[ii] += input[ii + 2] * fltr[2] weights = N.array([1.1, 2.2, 3.3]) type = N.uint8 a = N.arange(12, dtype = type) a.shape = (3,4) total = weights.sum() # No error first time, error second time for i in range(2): print "Iteration %d" % i r2 = ndimage.generic_filter1d(a, _filter_func, 3, axis = 0, origin = -1, extra_arguments = (weights,), extra_keywords = {'total': total}) Gives: [mb312@foundmachine tmp]$ python nd_debug.py Iteration 0 Iteration 1 Traceback (most recent call last): File "nd_debug.py", line 22, in ? extra_keywords = {'total': total}) File "/home/mb312/lib64/python2.4/site-packages/scipy/ndimage/filters.py", line 632, in generic_filter1d mode, cval, origin, extra_arguments, extra_keywords) MemoryError Has anyone got any tips on how I might go about debugging this? Sorry, I am a novice at debugging extension code. Best, Matthew
Hi Matthew On Thu, Sep 14, 2006 at 10:38:46PM +0100, Matthew Brett wrote:
(The ld filter error remains, but has been discussed elsewhere.)
I am getting that error too on an x86_64 machine. Has it in fact been discussed elsewhere? I think the thread you pointed to was just the error report wasn't it?
Actually I've appended a test script that reproduces it; the first call to ndimage.generic_filter1d works, but the second (in my script: identical) call generates a memory error, only on my x86_64 machine:
<snip script>
Has anyone got any tips on how I might go about debugging this? Sorry, I am a novice at debugging extension code.
Could you please run this through valgrind? To use valgrind, I do the following: 1. Generate a suppression file. This file tells valgrind which memory errors are expected. Since the latest numpy testsuite seems to be free of those gremlins (let's hold thumbs), you can generate the suppressions by doing: $ valgrind --gen-suppressions=all python -c 'import numpy; numpy.test()' 2>&1 | grep -v '==' > valgrind.supp Just check valgrind.supp over to make sure it doesn't contain any python errors or other garbage. You only need to generate this file once. 2. Run valgrind on the test script. I have the following in a file, valgrind-py, that I got from Albert: valgrind \ --tool=memcheck \ --leak-check=yes \ --error-limit=no \ --suppressions=valgrind-python.supp \ --num-callers=10 \ -v \ python $* so that I can simply run $ valgrind-py <python-filename> The resulting errors should point us in the right direction! Thanks for your effort. Stéfan
Hi,
I am getting that error too on an x86_64 machine. Has it in fact been discussed elsewhere? I think the thread you pointed to was just the error report wasn't it?
I think I tracked this one down and fixed it on my system: http://projects.scipy.org/scipy/scipy/ticket/264 Best, Matthew
On Fri, Sep 15, 2006 at 06:39:15PM +0100, Matthew Brett wrote:
Hi,
I am getting that error too on an x86_64 machine. Has it in fact been discussed elsewhere? I think the thread you pointed to was just the error report wasn't it?
I think I tracked this one down and fixed it on my system:
Hi Matthew I have to hand it to you; I quickly went over the code this morning and couldn't figure out what the heck was going on. I applied your patch. I'll file a numpy ticket for the remaining issues. Cheers Stéfan
On Fri, Sep 15, 2006 at 10:50:46PM +0200, Stefan van der Walt wrote:
On Fri, Sep 15, 2006 at 06:39:15PM +0100, Matthew Brett wrote:
Hi,
I am getting that error too on an x86_64 machine. Has it in fact been discussed elsewhere? I think the thread you pointed to was just the error report wasn't it?
I think I tracked this one down and fixed it on my system:
I have to hand it to you; I quickly went over the code this morning and couldn't figure out what the heck was going on. I applied your patch. I'll file a numpy ticket for the remaining issues.
Erm, yes, that's how we do it: foot in mouth and echo world-wide. Oh well, I can just as well finish the job. No need to worry about the "remaining issues", those ended up being spurious valgrind warnings. Regards Stéfan
participants (4)
-
Matthew Brett -
Michael Williams -
Nils Wagner -
Stefan van der Walt