[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 <wink -- but it smells like an extra decref>? suggestive-but-not-yet-proven-ly y'rs - tim
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