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

[Guido van Rossum]

> [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 ...

I tried this with smaller numbers on Linux, and it's pretty much the
same (some of the [startup...] messages are from my $PYTHONSTARTUP):

Python 2.2.2b1 (#21, Oct  7 2002, 15:15:32) 
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
[startup.py ...]
[no rl completer: No module named readline]
[startup.py done]
>>> b = {}
[16738 refs]
>>> for i in range(100000): b[i]=[i]*60
    

[6216740 refs]
>>> [6216740 refs]
>>> for k in range(100000): del b[k]
    
[116742 refs]
>>> b
{}
[116749 refs]
>>> 1   
1
[116749 refs]
>>> del b
[16748 refs]
>>> ^D
[16748 refs]
[exithandler()]
[5704 refs]

The extra references must be refs to the dummy value that the dict
implementation inserts when it deletes a value.

So this is not something to worry about.

--Guido van Rossum (home page: http://www.python.org/~guido/)