>>>>> "JH" == Jeremy Hylton <jeremy@beopen.com> writes:
>>>>> "NS" == Neil Schemenauer <nascheme@enme.ucalgary.ca> writes:
NS> Its hard to say. The GC code will probably pick up on a lot
NS> of problems because it touches many objects. On the other
NS> hand, it could be my bug.
It also appears to mask many problems. I just compiled out the
gcmodule (which is sadly undocumented, I believe) and I've just gotten
a number of new memory leaks. This is basically running a very simple
Python script:
-------------------- snip snip --------------------
'-'.join(('one',))
'-'.join((u'one',))
-------------------- snip snip --------------------
Will investigate further, but at first blush, they might be real
cycles created in the exception initialization code.
But anyway...
JH> Which leads me to ask, Barry, did you run purify on an
JH> interpreter with the latest stringobject.c?
...I'd actually expect the above script to leak *seq twice in the
current CVS string_join(). It doesn't, but then neither does
including the missing decrefs cause the objects to be decref'd extra
times. Interesting. Still I think string_join() needs to be patched
in two places to decref *seq (first, in the seqlen==1 clause, and
later just before the return PyUnicode_Join()).
I'll check in a patch, but would appreciate a proofread.
-Barry
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