AW: [Python-Dev] segmentation fault with python2.3a0 from cvs (original) (raw)
Guido van Rossum guido@python.org
Mon, 07 Oct 2002 15:29:59 -0400
- Previous message: AW: [Python-Dev] segmentation fault with python2.3a0 from cvs
- Next message: [Python-Dev] segmentation fault with python2.3a0 from cvs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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 "", line 1, in ? > > KeyError: 0 > > [1003458 refs] > > >>> print len(b.keys()) > > 0 > > [1003621 refs] > > > > The funny thing is, the memory allocated by pythond.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/)
- Previous message: AW: [Python-Dev] segmentation fault with python2.3a0 from cvs
- Next message: [Python-Dev] segmentation fault with python2.3a0 from cvs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]