AW: [Python-Dev] segmentation fault with python2.3a0 from cvs (original) (raw)
Tim Peters tim.one@comcast.net
Mon, 07 Oct 2002 15:07:30 -0400
- Previous message: AW: AW: [Python-Dev] segmentation fault with python2.3a0 from cvs
- Next message: AW: [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 ...
- Previous message: AW: AW: [Python-Dev] segmentation fault with python2.3a0 from cvs
- Next message: AW: [Python-Dev] segmentation fault with python2.3a0 from cvs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]