Re: [Numpy-discussion] Strange and hard to reproduce crash

[Charles R H. <cha...@gm...>]

On 10/30/06, Fernando Perez <fpe...@gm...> wrote:
>
> On 10/23/06, Travis Oliphant <oli...@ie...> wrote:
>
> > I've placed them in SVN (r3384):
> >
> > arraydescr_dealloc needs to do something like.
> >
> > if (self->fields == Py_None) {
> >     print something
> >     incref(self)
> >     return;
> > }
>
> Here is some more info.  We left a long-running job over the weekend
> with the prints you suggested.  Oddly, something happened at the OS
> level which killed our SSH connection to that machine, but the above
> numpy dealloc() warning never printed (we logged this).
>
> What did happen is that the refcount you suggested we print:
>
> sys.getrefcount(numpy.dtype('float'))
>
> eventually seems to have wrapped around and gone negative.  I'm
> attaching the log file with those print statements, the key point is
> that this happens eventually:
>
> PSVD Iteration  19
> Ref count  1989827662
> bar 444
> PSVD Iteration  0
> Ref count  2021353399
> PSVD Iteration  1
> Ref count  2143386207
> PSVD Iteration  2
> Ref count  -2001245193
> PSVD Iteration  3
> Ref count  -1915816437
> PSVD Iteration  4
> Ref count  -1902698473
>
> That refcount is for dtype('float') as indicated above.  Is it not a
> problem that this particular refcount goes negative?  Eventually it
> may continue increasing and hit a zero, point at which I imagine that
> the bad dealloc will occur.
>
> Are refcounts stored in signed 32-bit ints? Why? I'd have naively
> expected them to be stored in unsigned longs to avoid wraparound
> problems, but maybe I'm completely missing the real problem here.


I suspect the real problem is that the refcount keeps going up. Even if it
was unsigned it would eventually wrap to zero and with a bit of luck get
garbage collected. So probably something isn't decrementing the refcount.

Chuck