Menu
▾
▴
numpy-discussion
|
From: Damien M. <dj...@mi...> - 2006-06-15 05:23:03
|
Hi,
I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a
malloc fault in the check_types() self-test as it tries to free() a junk
pointer. In case you are not aware, OpenBSD's malloc() implementation
does a fair bit of randomisation that makes it (deliberately) sensitive
to memory management errors.
Instumenting the check_types test and scalartypes.inc.src's
gen_dealloc() and gen_alloc() functions I noticed that the error occurs
up after calling gen_dealloc() on a complex128scalar that was created as
check_types's "valb" variable as it is GC'd.
The check_types tests work fine on the complex64scalar type and all
the other preceeding types. I'm not familiar with the guts of numpy
at all (and I can't even find the declaration of the complex128scalar
type in the source). What difference between complex64scalar and
complex128scalar should I look for to debug this further?
A backtrace is below for the curious.
-d
(gdb) bt
#0 0x0ff49975 in kill () from /usr/lib/libc.so.39.1
#1 0x0ff822c3 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#2 0x0ff69649 in wrterror (p=0x2ff18460 "free_pages: pointer to wrong page")
at /usr/src/lib/libc/stdlib/malloc.c:434
#3 0x0ff6970b in wrtwarning (p=0x2ff18460 "free_pages: pointer to wrong page")
at /usr/src/lib/libc/stdlib/malloc.c:444
#4 0x0ff6ac53 in free_pages (ptr=0x7e0033b0, index=516111, info=0x0)
at /usr/src/lib/libc/stdlib/malloc.c:1343
#5 0x0ff6a6f4 in ifree (ptr=0x7e0033b0)
at /usr/src/lib/libc/stdlib/malloc.c:1770
#6 0x0ff6a8d1 in free (ptr=0x7e0033b0)
at /usr/src/lib/libc/stdlib/malloc.c:1838
#7 0x0d259117 in gentype_dealloc (v=0x7e0033b0) at scalartypes.inc.src:283
#8 0x0c5fc778 in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#9 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#10 0x0c60072f in fast_function () from /usr/local/lib/libpython2.4.so.0.0
#11 0x0c60036d in call_function () from /usr/local/lib/libpython2.4.so.0.0
#12 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#13 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#14 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#15 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#16 0x0c600c6b in ext_do_call () from /usr/local/lib/libpython2.4.so.0.0
#17 0x0c5fe83c in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
---Type <return> to continue, or q <return> to quit---
#18 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#19 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#20 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#21 0x0c5b2bd4 in instancemethod_call ()
from /usr/local/lib/libpython2.4.so.0.0
#22 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#23 0x0c600aa1 in do_call () from /usr/local/lib/libpython2.4.so.0.0
#24 0x0c6002fa in call_function () from /usr/local/lib/libpython2.4.so.0.0
#25 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#26 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#27 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#28 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#29 0x0c5b2bd4 in instancemethod_call ()
from /usr/local/lib/libpython2.4.so.0.0
#30 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#31 0x0c5e5c9f in slot_tp_call () from /usr/local/lib/libpython2.4.so.0.0
#32 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#33 0x0c600aa1 in do_call () from /usr/local/lib/libpython2.4.so.0.0
#34 0x0c6002fa in call_function () from /usr/local/lib/libpython2.4.so.0.0
#35 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#36 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#37 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#38 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
---Type <return> to continue, or q <return> to quit---
#39 0x0c600c6b in ext_do_call () from /usr/local/lib/libpython2.4.so.0.0
#40 0x0c5fe83c in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#41 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#42 0x0c5bf2f2 in function_call () from /usr/local/lib/libpython2.4.so.0.0
#43 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#44 0x0c5b2bd4 in instancemethod_call ()
from /usr/local/lib/libpython2.4.so.0.0
#45 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#46 0x0c5e5c9f in slot_tp_call () from /usr/local/lib/libpython2.4.so.0.0
#47 0x0c5abe40 in PyObject_Call () from /usr/local/lib/libpython2.4.so.0.0
#48 0x0c600aa1 in do_call () from /usr/local/lib/libpython2.4.so.0.0
#49 0x0c6002fa in call_function () from /usr/local/lib/libpython2.4.so.0.0
#50 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#51 0x0c6007b0 in fast_function () from /usr/local/lib/libpython2.4.so.0.0
#52 0x0c60036d in call_function () from /usr/local/lib/libpython2.4.so.0.0
#53 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#54 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#55 0x0c60072f in fast_function () from /usr/local/lib/libpython2.4.so.0.0
#56 0x0c60036d in call_function () from /usr/local/lib/libpython2.4.so.0.0
#57 0x0c5fe42f in PyEval_EvalFrame () from /usr/local/lib/libpython2.4.so.0.0
#58 0x0c5feeb6 in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.4.so.0.0
#59 0x0c5fc1a7 in PyEval_EvalCode () from /usr/local/lib/libpython2.4.so.0.0
#60 0x0c61d060 in run_node () from /usr/local/lib/libpython2.4.so.0.0
---Type <return> to continue, or q <return> to quit---
#61 0x0c61c0b1 in PyRun_SimpleFileExFlags ()
from /usr/local/lib/libpython2.4.so.0.0
#62 0x0c61ba49 in PyRun_AnyFileExFlags ()
from /usr/local/lib/libpython2.4.so.0.0
#63 0x0c622bab in Py_Main () from /usr/local/lib/libpython2.4.so.0.0
#64 0x1c000d60 in main ()
|
|
From: Damien M. <dj...@mi...> - 2006-06-15 05:24:12
|
On Thu, 15 Jun 2006, Damien Miller wrote: > Hi, > > I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a bah, I'm actually using numpy-0.9.8 (not 0.9.5). -d |
|
From: David M. C. <co...@ph...> - 2006-06-15 05:44:58
|
On Thu, 15 Jun 2006 15:22:57 +1000 (EST) Damien Miller <dj...@mi...> wrote: > Hi, > > I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a > malloc fault in the check_types() self-test as it tries to free() a junk > pointer. In case you are not aware, OpenBSD's malloc() implementation > does a fair bit of randomisation that makes it (deliberately) sensitive > to memory management errors. > > Instumenting the check_types test and scalartypes.inc.src's > gen_dealloc() and gen_alloc() functions I noticed that the error occurs > up after calling gen_dealloc() on a complex128scalar that was created as > check_types's "valb" variable as it is GC'd. > > The check_types tests work fine on the complex64scalar type and all > the other preceeding types. I'm not familiar with the guts of numpy > at all (and I can't even find the declaration of the complex128scalar > type in the source). What difference between complex64scalar and > complex128scalar should I look for to debug this further? Can you update to the latest svn? We may have fixed it already: valgrind is showing up nothing for me. A complex128scalar is a complex number made up of doubles (float64); a complex64 is one of floats (float32). -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
|
From: Travis O. <oli...@ie...> - 2006-06-15 05:57:18
|
Damien Miller wrote: > Hi, > > I'm trying to make an OpenBSD package on numpy-0.9.5, but it receives a > malloc fault in the check_types() self-test as it tries to free() a junk > pointer. In case you are not aware, OpenBSD's malloc() implementation > does a fair bit of randomisation that makes it (deliberately) sensitive > to memory management errors. > This problem has been worked around in NumPy SVN. It is a problem with Python that has been fixed in Python SVN as well. You can either comment-out the test or update to latest SVN. -Travis |
|
From: Damien M. <dj...@mi...> - 2006-06-15 08:56:36
|
David M. Cooke wrote: > Can you update to the latest svn? We may have fixed it already: valgrind is > showing up nothing for me. Ok, but dumb question: how do I check out the SVN trunk? Sourceforge lists details for CVS only... (unless I'm missing something) -d |
|
From: Arnd B. <arn...@we...> - 2006-06-15 09:03:32
|
On Thu, 15 Jun 2006, Damien Miller wrote: > David M. Cooke wrote: > > Can you update to the latest svn? We may have fixed it already: valgrind is > > showing up nothing for me. > > Ok, but dumb question: how do I check out the SVN trunk? Sourceforge > lists details for CVS only... (unless I'm missing something) See "Bleeding-edge repository access" under http://www.scipy.org/Download I.e. for numpy: svn co http://svn.scipy.org/svn/numpy/trunk numpy Best, Arnd |
|
From: Fernando P. <fpe...@gm...> - 2006-06-15 09:03:35
|
On 6/15/06, Damien Miller <dj...@mi...> wrote: > David M. Cooke wrote: > > Can you update to the latest svn? We may have fixed it already: valgrind is > > showing up nothing for me. > > Ok, but dumb question: how do I check out the SVN trunk? Sourceforge > lists details for CVS only... (unless I'm missing something) http://scipy.org/Developer_Zone Cheers, f |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X