Over the last week, I checked in fixes for two distinct broad causes of segfaults in code using weakrefs with callbacks. The bugs have been there since weakrefs were introduced, but for whatever reason nobody bumped into them (knowingly) until Jim Fulton and Thomas Heller happened to provoke both, independently, within a day of each other. It was especially easy under Thomas's scenario *not* to get a segfault in a release build, but to suffer random memory corruption instead (if the double-deallocation provoked pymalloc into handing out the same chunk of memory to two distinct objects alive at the same time -- and that is, alas, a likely outcome). I suspect these bugs hid for so long because it's taken Pythoneers a long time to discover why weakrefs can be so cool, and start to build serious apps on top of them. Casual programmers aren't likely to use weakrefs at all, but once you've built a cache based on weakrefs in a large app, weakrefs become critical to your code and your design. So I think either of these fixes is enough to justify a bugfix release, and having two of them makes a compelling case. What say we get 2.3.3 in motion? I did the weakref checkins already on the trunk and on release23-maint; Thomas Heller confirmed that his problems went away on release23-maint, and Jim Fulton confirmed that his Zope3 segfaults went away on the released 2.3.2 + a patch identical in all functional respects to what got checked in (the new test_weakref test cases, and some code comments, were different). If we get 2.3.3c1 out in early December, we could release 2.3.3 final before the end of the year, and start 2004 with a 100% bug-free codebase <wink>.
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