AW: [Python-Dev] segmentation fault with python2.3a0 from cvs

Tim Peters tim.one@comcast.net
Mon, 07 Oct 2002 15:07:30 -0400


[Gerson Kurz]

> Python 2.3a0 (#29, Oct  7 2002, 19:54:53) [MSC 32 bit (Intel)] on win32
>  b = {}
> > [3319 refs]
> > >>> for i in range(1000000):
> > ...     b[i]=[i]*60
> > ...
> > [62003414 refs]
> > >>> for k in range(1000000):
> > ...     del b[k]
> > ...
> > [1003419 refs]
> > >>> print b[0]
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > KeyError: 0
> > [1003458 refs]
> > >>> print len(b.keys())
> > 0
> > [1003621 refs]
> >
> > The funny thing is, the memory allocated by python_d.exe
> *INCREASES* when I
> > do the del b[k]-bit thingy. OK, so I guess its time to do a gc:

[Guido]
> No, there are no cycles in the data structures you create here.
>
> I suspect another CYGWIN malloc bug.

Unless I'm reading it wrong, Gerson wasn't using Cygwin there.  The int free
list is immortal and unbounded, and the structure of the loop interleaves
int allocations with list allocs and dict resizings.  So it's unlikely
memory will be "given back to the system" no matter which platform this is
done on -- it's too fragmented.

It doesn't make sense that sysreftotal isn't falling, though.  It's as if
the int free list were holding on to references ...