> The following program: > > import rexec > while 1: > x = rexec.RExec() > del x > > leaks memory at a fantastic rate. > > It seems clear (?) that this is due to the call to "set_rexec" at > rexec.py:140, which creates a circular reference between the `rexec' > and `hooks' objects. (There's even a nice comment to that effect). > > I'm curious however as to why the spiffy new cyclic-garbage collector > doesn't pick this up? Me too. I turned on gc debugging (gc.set_debug(077) :-) and got messages suggesting that it is not collecting everything. The output looks like this: . . . gc: collecting generation 0... gc: objects in each generation: 764 6726 89174 gc: done. gc: collecting generation 1... gc: objects in each generation: 0 8179 89174 gc: done. gc: collecting generation 0... gc: objects in each generation: 764 0 97235 gc: done. gc: collecting generation 0... gc: objects in each generation: 757 747 97184 gc: done. gc: collecting generation 0... gc: objects in each generation: 764 1386 97184 gc: done. gc: collecting generation 0... gc: objects in each generation: 757 2082 97184 gc: done. gc: collecting generation 0... gc: objects in each generation: 764 2721 97184 gc: done. gc: collecting generation 0... gc: objects in each generation: 757 3417 97184 gc: done. gc: collecting generation 0... gc: objects in each generation: 764 4056 97184 gc: done. . . . With the third number growing each time a "generation 1" collection is done. Maybe Neil can shed some light? The gc.garbage list is empty. This is about as much as I know about the GC stuff... --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4