The problem reappeared today, same error, always in the line : xp = (x-self.loc) * (1/self.scale)
When multiplying an array with a float. Matthieu 2007/10/19, Matthieu Brucher <[EMAIL PROTECTED]>: > > Oups, sorry for the sending twice, we have some problem with our DNS in > Strasbourg :( > > 2007/10/19, Matthieu Brucher <[EMAIL PROTECTED] >: > > > > Here is an excerpt of the stack on the numpy svn of wednesday : > > > > #0 0x40000402 in __kernel_vsyscall () > > #1 0x00b8e382 in [EMAIL PROTECTED] () from /lib/libpthread.so.0 > > #2 0x080fe5b7 in PyThread_release_lock (lock=0x80d0fb2) at > > Python/thread_pthread.h:374 > > #3 0x080d0fb2 in PyEval_SaveThread () at Python/ceval.c:299 > > #4 0x4064ec7a in dotblas_innerproduct (dummy=0x0, args=0x960522c) at > > numpy/core/blasdot/_dotblas.c:835 > > #5 0x0811ecf1 in PyCFunction_Call (func=0x960522c, arg=0x80cfec7, > > kw=0x942068c) at Objects/methodobject.c:73 > > #6 0x080cfec7 in call_function (pp_stack=0x0, oparg=1) at > > Python/ceval.c:3564 > > #7 0x080cb19a in PyEval_EvalFrameEx. () at Python/ceval.c:2267 > > #8 0x080ca848 in PyEval_EvalCodeEx. () at Python/ceval.c:2831 > > #9 0x0811de5b in function_call (func=0x0, arg=0x960516c, kw=0x965b148) > > at Objects/funcobject.c:517 > > #10 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x960516c, kw=0x8061a66) > > at Objects/abstract.c:1860 > > #11 0x08061a66 in instancemethod_call (func=0x95f16ac, arg=0x94f5824, > > kw=0x805bdb6) at Objects/classobject.c:2497 > > #12 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x95f16ac, kw=0x80a86e9) > > at Objects/abstract.c:1860 > > #13 0x080a86e9 in slot_tp_call (self=0xbf975c78, args=0x0, > > kwds=0x805bdb6) at Objects/typeobject.c:4633 > > #14 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x95f16ac, kw=0x80d017b) > > at Objects/abstract.c:1860 > > #15 0x080d017b in do_call (func=0x0, pp_stack=0x1, na=1, nk=154955456) > > at Python/ceval.c:3775 > > #16 0x080cfd56 in call_function (pp_stack=0x0, oparg=1) at > > Python/ceval.c:3587 > > #17 0x080cb19a in PyEval_EvalFrameEx. () at Python/ceval.c:2267 > > #18 0x080ca848 in PyEval_EvalCodeEx. () at Python/ceval.c:2831 > > #19 0x0811de5b in function_call (func=0x0, arg=0x960520c, kw=0x30) at > > Objects/funcobject.c:517 > > #20 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x960520c, kw=0x8061a66) > > at Objects/abstract.c:1860 > > #21 0x08061a66 in instancemethod_call (func=0x95ecbac, arg=0x94f57d4, > > kw=0x805bdb6) at Objects/classobject.c:2497 > > #22 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x95ecbac, kw=0x80a86e9) > > at Objects/abstract.c:1860 > > #23 0x080a86e9 in slot_tp_call (self=0xbf97609c, args=0x0, > > kwds=0x805bdb6) at Objects/typeobject.c:4633 > > #24 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x95ecbac, kw=0x80d017b) > > at Objects/abstract.c:1860 > > #25 0x080d017b in do_call (func=0x0, pp_stack=0x1, na=1, nk=156957888) > > at Python/ceval.c:3775 > > #26 0x080cfd56 in call_function (pp_stack=0x0, oparg=1) at > > Python/ceval.c:3587 > > #27 0x080cb19a in PyEval_EvalFrameEx. () at Python/ceval.c:2267 > > #28 0x080ca848 in PyEval_EvalCodeEx. () at Python/ceval.c:2831 > > #29 0x0811de5b in function_call (func=0x0, arg=0x960518c, kw=0x9548a1) > > at Objects/funcobject.c:517 > > #30 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x960518c, kw=0x8061a66) > > at Objects/abstract.c:1860 > > #31 0x08061a66 in instancemethod_call (func=0x960526c, arg=0x95fc874, > > kw=0x805bdb6) at Objects/classobject.c:2497 > > #32 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x960526c, kw=0x80a86e9) > > at Objects/abstract.c:1860 > > #33 0x080a86e9 in slot_tp_call (self=0xbf9764c0, args=0x0, > > kwds=0x805bdb6) at Objects/typeobject.c:4633 > > #34 0x0805bdb6 in PyObject_Call (func=0x0, arg=0x960526c, kw=0x80d017b) > > at Objects/abstract.c:1860 > > #35 0x080d017b in do_call (func=0x0, pp_stack=0x1, na=1, nk=157640136) > > at Python/ceval.c:3775 > > #36 0x080cfd56 in call_function (pp_stack=0x0, oparg=1) at > > Python/ceval.c:3587 > > #37 0x080cb19a in PyEval_EvalFrameEx. () at Python/ceval.c:2267 > > #38 0x080ca848 in PyEval_EvalCodeEx. () at Python/ceval.c:2831 > > #39 0x0811de5b in function_call (func=0x0, arg=0x95f260c, kw=0x0) at > > Objects/funcobject.c:517 > > #40 0x0805bdb6 in PyObject_Call (func=0x9609934, arg=0x95f260c, > > kw=0x8061a66) at Objects/abstract.c:1860 > > > > Seems that > > > > 2007/10/15, Travis E. Oliphant < [EMAIL PROTECTED] >: > > > > > > Matthieu Brucher wrote: > > > > > > > > The problem is that there is a data-type reference counting > > > error some > > > > where that is attempting to deallocate the built-in data-type > > > 'l' > > > > > > > > > > > > > > > > That's what I supposed, but I couldn't find the reason why it wanted > > > > to do this > > > > > > > > > > > > It's not really a Python error but a logging. The code won't > > > let you > > > > deallocate the built-ins, but it will tell you that something > > > > tried to. > > > > > > > > Reference counting on data-types is easy to get wrong > > > > (particularly with > > > > Pyrex extension modules) because most calls consume a reference > > > to the > > > > data-type (if they return an object that contains a reference > > > to the > > > > data-type). > > > > > > > > It is a bug, and it would be nice to figure it out, but that > > > would > > > > require the code that caused it. > > > > > > > > > > > > I've updated my numpy version to the latest svn, the behaviour seems > > > > > > > to be different (more warnings), I'll try to give more information > > > > about the error, but giving the whole code will not be simple (it > > > uses > > > > a big data file that seems to trigger the error as with other data > > > > files, the error didn't show up :() > > > > > > > > > > There are two types of errors that can occur with reference counting > > > on > > > data-types. > > > > > > 1) There are too many DECREF's --- this gets us to the error quickly > > > and > > > is usually easy to reproduce > > > 2) There are too many INCREF's (the reference count keeps going up > > > until > > > the internal counter wraps around to 0 and deallocation is attempted) > > > --- this error is harder to reproduce and usually takes a while before > > > > > > it happens in the code. > > > > > > > > > -Travis > > > > > > _______________________________________________ > > > Numpy-discussion mailing list > > > [email protected] > > > http://projects.scipy.org/mailman/listinfo/numpy-discussion > > > > > > > >
_______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
