On Fri, 6 Dec 2002, Tim Peters wrote: > If someone is up for a good weekend puzzle, try this on for size. I'd like > to multitask this, if possible. I've found the same leak under Linux+GCC 3.2 (Redhat 8) with CVS HEAD Python, compiled with debugging: Testing the Python implementation. ********** total refs: 35554 ********** total refs: 35591 ********** total refs: 35628 ********** total refs: 35665 ********** total refs: 35702 (leaking 37 refs per run) Testing the C implementation. ********** total refs: 31262 ********** total refs: 31272 ********** total refs: 31282 ********** total refs: 31292 (leaking 10 refs per run) HOWEVER, the leak disapears when Python is compiled normally, without debugging. I've also added some instrumentation to the interpreter and have determined that the leak is not occuring in a garbage collected object (anything in gc.get_objects()) that exists after the test-suite has been run. > Even if you can't make time to dig into this, it would help a little to know > what the C and Python leak rates are on a different platform. Yes -- at least on Linux+GCC 3.2 (Redhat 8.0). > Heck, it would help to know whether the C code even compiles and the tests > pass on a different platform (I'm running Win2K + current CVS Python + > MSVC 6 here). Yes on that too. I'm going to start a binary search on the test suite to see if I can isolate a minimal sequence that shows the leak. -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
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