Error in deallocation ?
Hi I keep on getting this error : *** Reference count error detected: an attempt was made to deallocate 7 (l) *** It happens on numpy calls (multiplications, call to inner(), ...), but I didn't find the real reason. I'm using Numpy '1.0.4.dev3875' with Python 2.5.1. Someone has a hint to solve this ? Matthieu
Matthieu Brucher wrote:
Hi
I keep on getting this error :
*** Reference count error detected: an attempt was made to deallocate 7 (l) ***
It happens on numpy calls (multiplications, call to inner(), ...), but I didn't find the real reason. I'm using Numpy ' 1.0.4.dev3875' with Python 2.5.1.
Someone has a hint to solve this ?
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' 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. Thanks, -Travis O.
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 :() Matthieu
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
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.
The error showed up again with a simple operation : File "/home/brucher/local/src/include/toolbox/stats/kernels/gaussian.py", line 60, in __call__ xp = (x-self.loc) * (1/self.scale) Where x and self.loc are arrays abd self.scale is an integer. The error as it was given : *** Reference count error detected: an attempt was made to deallocate 7 (l) *** *** Reference count error detected: an attempt was made to deallocate 7 (l) *** *** Reference count error detected: an attempt was made to deallocate 7 (l) *** I don't know if it is too many INCREF, but I doubt it. It happens in a loop where I treat a bunch of 3D images each time (64*64*64*3), and it crashes after some dozens of them. I have no problem when I treat small 2D images (128*128), but far more samples. Matthieu
Matthieu Brucher wrote:
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.
The error showed up again with a simple operation : File "/home/brucher/local/src/include/toolbox/stats/kernels/gaussian.py", line 60, in __call__ xp = (x-self.loc) * (1/self.scale) Where x and self.loc are arrays abd self.scale is an integer.
The error as it was given :
*** Reference count error detected: an attempt was made to deallocate 7 (l) *** *** Reference count error detected: an attempt was made to deallocate 7 (l) *** *** Reference count error detected: an attempt was made to deallocate 7 (l) ***
I don't know if it is too many INCREF, but I doubt it. It happens in a loop where I treat a bunch of 3D images each time (64*64*64*3), and it crashes after some dozens of them. I have no problem when I treat small 2D images (128*128), but far more samples.
Can't you emulate this behaviour with signals different than images ? (say random signal of 64*64*64*3 samples). If the process does not require a long processing time (say a couple of minutes), then you may be able to use massif tool from valgrind, which may be helpful to detect too many INCREF. For DECREF, then the default memory checker from valgrind should be useful as well. If it does take only a couple of minutes, it is then relatively easy to "bisect" the code to spot the error (once you get through the C level, it is easy to see the problem, if you can reproduce it, in my experience). cheers, David
Can't you emulate this behaviour with signals different than images ? (say random signal of 64*64*64*3 samples).
I wish I could, but this behaviour only shows up on this peculiar data set :( If the process does not
require a long processing time (say a couple of minutes), then you may be able to use massif tool from valgrind, which may be helpful to detect too many INCREF. For DECREF, then the default memory checker from valgrind should be useful as well.
If it does take only a couple of minutes, it is then relatively easy to "bisect" the code to spot the error (once you get through the C level, it is easy to see the problem, if you can reproduce it, in my experience).
Unfortunately, the process is very long, there are several optimizations in the process, the whole thing in a EM-like algorithm, and the crash does not occur with the first image, it is later. Matthieu
Matthieu Brucher wrote:
Can't you emulate this behaviour with signals different than images ? (say random signal of 64*64*64*3 samples).
I wish I could, but this behaviour only shows up on this peculiar data set :(
It always happens at the same time ?
Unfortunately, the process is very long, there are several optimizations in the process, the whole thing in a EM-like algorithm, and the crash does not occur with the first image, it is later.
Can you observe some 'funky' memory behaviour while the process is running ? For example, does the memory keeps increasing after each dataset ?
I wish I could, but this behaviour only shows up on this peculiar data set :( It always happens at the same time ?
Yes. Perhaps debugging the process will sort things out ?
Unfortunately, the process is very long, there are several
optimizations in the process, the whole thing in a EM-like algorithm, and the crash does not occur with the first image, it is later. Can you observe some 'funky' memory behaviour while the process is running ? For example, does the memory keeps increasing after each dataset ?
Good question, in fact it should because I'm saving the result in a list before I pickle it (but in fact I have to change this process as pickle cannot handle the images I'm using, but that's another problem). So it should increase, but not too much. I'll check this. Matthieu
Matthieu Brucher wrote:
> I wish I could, but this behaviour only shows up on this peculiar data > set :( It always happens at the same time ?
Yes. Perhaps debugging the process will sort things out ?
As said, my approach to debugging this kind of thing is to get out of python ASAP. And once you manage to reproduce the result when calling only a couple of python functions, then you use massif or memcheck. The reason to get out of python is that tools like valgrind can only give you meaningful informations at the C level, and it is difficult to make the link between C and python calls, if not impossible in all but trivial cases. But when you can get this kind of graphs: http://valgrind.org/docs/manual/ms-manual.html Then the problem is "solved", at least in my limited experience. David
As said, my approach to debugging this kind of thing is to get out of python ASAP. And once you manage to reproduce the result when calling only a couple of python functions, then you use massif or memcheck.
I agree with you, the problem is that I do not use directly C functions and that I do not know how I can reproduce the result with a minimal example. I know I've had once a Numpy problem that was solved by recompiling Numpy completely, but here, I do not possess a first clue to help me track this bug. The reason to get out of python is that tools like valgrind can only
give you meaningful informations at the C level, and it is difficult to make the link between C and python calls, if not impossible in all but trivial cases.
But when you can get this kind of graphs:
http://valgrind.org/docs/manual/ms-manual.html
Then the problem is "solved", at least in my limited experience.
Compltely agreed. Matthieu
Matthieu Brucher wrote:
As said, my approach to debugging this kind of thing is to get out of python ASAP. And once you manage to reproduce the result when calling only a couple of python functions, then you use massif or memcheck.
I agree with you, the problem is that I do not use directly C functions and that I do not know how I can reproduce the result with a minimal example.
Yes, that's why I suggested looking at the memory usage (using top or something else). Because maybe the problem can be spotted long before seeing it happening, hence having smaller code (which you could e.g. post, etc...) But if you can reproduce it with 128*128 images, then maybe it is quick enough to run the whole thing under massif ? cheers, David
I agree with you, the problem is that I do not use directly C functions and that I do not know how I can reproduce the result with a minimal example. Yes, that's why I suggested looking at the memory usage (using top or something else). Because maybe the problem can be spotted long before seeing it happening, hence having smaller code (which you could e.g. post, etc...)
For the moment nothing unusual, the memory use seems to be stable. But if you can reproduce it with 128*128 images, then maybe it is quick
enough to run the whole thing under massif ?
I'll try it this night (because it is very very long, so with the simulator...) Thanks for the help ;) Matthieu
Matthieu Brucher wrote:
> I agree with you, the problem is that I do not use directly C > functions and that I do not know how I can reproduce the result with a > minimal example. Yes, that's why I suggested looking at the memory usage (using top or something else). Because maybe the problem can be spotted long before seeing it happening, hence having smaller code (which you could e.g. post, etc...)
For the moment nothing unusual, the memory use seems to be stable.
But if you can reproduce it with 128*128 images, then maybe it is quick enough to run the whole thing under massif ?
I'll try it this night (because it is very very long, so with the simulator...)
Yes, that's the worse cases, of course. For those cases, I wish we could use numpy with COUNT_ALLOCS. Unfortunately, using numpy in this case is impossible (it crashes at import, and I've never tracked down the problem; maybe your problem may be enough of an incentive to start again): http://mail.python.org/pipermail/python-list/2003-May/206256.html cheers, David
I'll try it this night (because it is very very long, so with the simulator...) Yes, that's the worse cases, of course. For those cases, I wish we could use numpy with COUNT_ALLOCS. Unfortunately, using numpy in this case is impossible (it crashes at import, and I've never tracked down the problem; maybe your problem may be enough of an incentive to start again):
http://mail.python.org/pipermail/python-list/2003-May/206256.html
The problem is I don't have time for this at the moment, I have to develop my algorithm for my PhD, and if one does not work, I'll try another one, but this is strange because this algorithm worked in the past... BTW, I can't use massif. Although the normal algorithm does not use more than 150MB, with massif, it goes higher than 2.7GB, and this is before the really hungry process. Matthieu
On 10/17/07, Matthieu Brucher <matthieu.brucher@gmail.com> wrote:
I'll try it this night (because it is very very long, so with the simulator...) Yes, that's the worse cases, of course. For those cases, I wish we could use numpy with COUNT_ALLOCS. Unfortunately, using numpy in this case is impossible (it crashes at import, and I've never tracked down the problem; maybe your problem may be enough of an incentive to start again):
http://mail.python.org/pipermail/python-list/2003-May/206256.html
The problem is I don't have time for this at the moment, I have to develop my algorithm for my PhD, and if one does not work, I'll try another one, but this is strange because this algorithm worked in the past...
By incentive, I meant incentive for me, not for you :) I think this could be really helpful for other problems if this kind as well.
BTW, I can't use massif. Although the normal algorithm does not use more than 150MB, with massif, it goes higher than 2.7GB, and this is before the really hungry process.
Using massif with code using a large number of python code is clearly a no no, since it uses so much malloc. Sometimes, you can just stop the thing when it is growing up, and watching the resulting graphs. But this is no fun, and if you have no time... David
The problem is I don't have time for this at the moment, I have to develop my algorithm for my PhD, and if one does not work, I'll try another one, but this is strange because this algorithm worked in the past...
By incentive, I meant incentive for me, not for you :) I think this could be really helpful for other problems if this kind as well.
But as you have the same problems than me ;)
than 150MB, with massif, it goes higher than 2.7GB, and this is before
really hungry process. Using massif with code using a large number of python code is clearly a no no, since it uses so much malloc. Sometimes, you can just stop
BTW, I can't use massif. Although the normal algorithm does not use more the the thing when it is growing up, and watching the resulting graphs. But this is no fun, and if you have no time...
It's manily that it crashes when the second file is loaded into memory, the model that will be used for this data isn't even loaded and thus the value of the result is zero :( Strange though (IMHM) that massif needs to allocate so much memory for this little data. Matthieu
Oups, I'm wrong, the process happened this time with the 128² images and not the 3D images. I'll try to check a little bit further. Matthieu 2007/10/17, Matthieu Brucher <matthieu.brucher@gmail.com>:
Can't you emulate this behaviour with signals different than images ?
(say random signal of 64*64*64*3 samples).
I wish I could, but this behaviour only shows up on this peculiar data set :(
If the process does not
require a long processing time (say a couple of minutes), then you may be able to use massif tool from valgrind, which may be helpful to detect too many INCREF. For DECREF, then the default memory checker from valgrind should be useful as well.
If it does take only a couple of minutes, it is then relatively easy to "bisect" the code to spot the error (once you get through the C level, it is easy to see the problem, if you can reproduce it, in my experience).
Unfortunately, the process is very long, there are several optimizations in the process, the whole thing in a EM-like algorithm, and the crash does not occur with the first image, it is later.
Matthieu
Here is an excerpt of the stack on the numpy svn of wednesday : #0 0x40000402 in __kernel_vsyscall () #1 0x00b8e382 in sem_post@GLIBC_2.0 () 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 the bug could be somewhere in the handling of the dot blas module ? Matthieu 2007/10/15, Travis E. Oliphant <oliphant@enthought.com>:
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 Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
It seems this could be a deadlock somewhere ? The line 835 is where threads are allowed. I had another problem today with the same instruction ((x-self.loc) * (1/self.scale)), the computation just hung. I'm trying to test without the thread lock. Matthieu 2007/10/19, Matthieu Brucher <matthieu.brucher@gmail.com>:
Here is an excerpt of the stack on the numpy svn of wednesday :
#0 0x40000402 in __kernel_vsyscall () #1 0x00b8e382 in sem_post@GLIBC_2.0 () 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 the bug could be somewhere in the handling of the dot blas module ?
Matthieu
2007/10/15, Travis E. Oliphant <oliphant@enthought.com >:
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 Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
Here is an excerpt of the stack on the numpy svn of wednesday : #0 0x40000402 in __kernel_vsyscall () #1 0x00b8e382 in sem_post@GLIBC_2.0 () 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 <oliphant@enthought.com>:
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 Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Oups, sorry for the sending twice, we have some problem with our DNS in Strasbourg :( 2007/10/19, Matthieu Brucher <matthieu.brucher@gmail.com>:
Here is an excerpt of the stack on the numpy svn of wednesday :
#0 0x40000402 in __kernel_vsyscall () #1 0x00b8e382 in sem_post@GLIBC_2.0 () 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 <oliphant@enthought.com >:
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 Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
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 <matthieu.brucher@gmail.com>:
Oups, sorry for the sending twice, we have some problem with our DNS in Strasbourg :(
2007/10/19, Matthieu Brucher <matthieu.brucher@gmail.com >:
Here is an excerpt of the stack on the numpy svn of wednesday :
#0 0x40000402 in __kernel_vsyscall () #1 0x00b8e382 in sem_post@GLIBC_2.0 () 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 < oliphant@enthought.com >:
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 Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Does someone have a clue ? I'm starting getting this with all my datasets, always at the same line ! Matthieu 2007/10/23, Matthieu Brucher <matthieu.brucher@gmail.com>:
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 < matthieu.brucher@gmail.com>:
Oups, sorry for the sending twice, we have some problem with our DNS in Strasbourg :(
2007/10/19, Matthieu Brucher <matthieu.brucher@gmail.com >:
Here is an excerpt of the stack on the numpy svn of wednesday :
#0 0x40000402 in __kernel_vsyscall () #1 0x00b8e382 in sem_post@GLIBC_2.0 () 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 < oliphant@enthought.com >:
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 Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- French PhD student Website : http://miles.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
participants (4)
-
David Cournapeau -
David Cournapeau -
Matthieu Brucher -
Travis E. Oliphant