On Tue, Jul 11, 2000 at 01:05:10AM +0000, Peter Schneider-Kamp wrote:

I wouldn't bet my life on it, but I don't think the GC code is responsible.

Its hard to say. The GC code will probably pick up on a lot of problems because it touches many objects. On the other hand, it could be my bug. I'm prettly limited here as my computer is somewhere between Calgary and Reston as I type this. I will try to find the problem though. Neil

[Peter Schneider-Kamp]

I wouldn't bet my life on it, but I don't think the GC code is responsible.

[Neil Schemenauer]

Its hard to say.

I'll second that <wink>.

The GC code will probably pick up on a lot of problems because it touches many objects. On the other hand, it could be my bug. I'm prettly limited here as my computer is somewhere between Calgary and Reston as I type this. I will try to find the problem though.

I also doubt it's gc's fault: the recent patches to the gc code were absolutely vanilla, this all worked fine (at least for me) yesterday, and it's failing for multiple people on multiple platforms today. (BTW, Barry, your core.py does not fail under my Windows build.) I haven't had more time tonight to look at it, though, and won't tomorrow either. "Somehow or other" the list of objects it's crawling over is totally hosed (length 3, first one is a legit string object, last two seemingly random trash). If I remembered how to do this with CVS, I'd just do a mindless binary search over the last day's patches, rebuilding until the problem goes away ... OK, if I back out *only* Jeremy's very recent patch to stringobject.c: http://www.python.org/pipermail/python-checkins/2000-July/006424.html all my Windows gc failures go away. I picked on that patch because it's the only non-trivial patch that's gone in recently to a popular part of the code. Jeremy, want to double-check your refcounts ? suggestive-but-not-yet-proven-ly y'rs - tim

...

...

...

...

"JH" == Jeremy Hylton writes:

JH> Which leads me to ask, Barry, did you run purify on an JH> interpreter with the latest stringobject.c? Yes. And I did get other memory errors before the core, which I should have looked at more carefully. Looks like that might have been it. My fault for encouraging you to check your changes in without looking at them, and then I had to disappear for a few hours. I've got them now and am looking at the code (I see a missing decref, but that should only leak memory). Will Purify shortly. -Barry

...

...

...

...

"JH" == Jeremy Hylton writes:

...

...

...

...

"NS" == Neil Schemenauer 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