As I am sure some have noticed, as part of my dissertation I have been trying to fix the various crashers. I currently have some patches in SF for some of the crashers. The other ones Armin and I have been talking, while others I have not started yet. Review for the patches or help with fixing the ones I have not gotten to would be great. http://www.python.org/sf/1202533 has a potential fix for the infinite_rec_*.py crashers. PyObject_Call() basically needs a recursion check. But there were some issues with PyErr_NormalizeException() blowing up while trying to normalize the exception, that also needs to watch out for hitting the recursion limit and returning a RuntimeError that does not need normalization itself. http://www.python.org/sf/1377858 has a patch for weakref_in_del.py . Turns out if you create a new weakref in a __del__ for self the weakref is never notified that self is gone and it no longer has a valid weakref to anything. Added a check after __del__ is called to make sure that if any weakrefs were created that they get cleared. http://www.python.org/sf/1303614 is a discussion currently between Armin and I on how to handle del___dict__.py . Looks like more careful reference counting is needed, but Armin is worried about a performance hit. There is also a patch there to fix loosing_dict_ref.py . dangerous_subclassing.py, modify_dict_attr.py, and nasty_eq_vs_dict.py I have not gotten to yet. I am ignoring bogus_code_obj.py, gc_inspection.py, and recursive_call.py since they either require setting the recursion depth higher or involve an extension module. -Brett
Brett Cannon wrote:
As I am sure some have noticed, as part of my dissertation I have been trying to fix the various crashers.
Nice project. One quick thought: Any crasher that relies on gc.get_referrers() should not be considered a bug. The codebase should not be convoluted, complexified, obfucated, altered, touched, or slowed down just prevent perverse, sadistic safe-cracking using this tool. The docs are clear on this subject: "Care must be taken when using objeccts returned by get_referrers() becasue some of them could still be under construction and hence in a temporarily invalid state. Avoid using get_referrers() for any purpose other than debugging." Raymond
On 7/10/06, Raymond Hettinger <rhettinger@ewtllc.com> wrote:
Right. That is on the list of crashers I am ignoring. The codebase should not be convoluted,
And I am trying to make sure all the fixes are not superfluous but fix actual issues in the code and behaviour of Python. -Brett
Brett Cannon wrote:
As I am sure some have noticed, as part of my dissertation I have been trying to fix the various crashers.
Nice project. One quick thought: Any crasher that relies on gc.get_referrers() should not be considered a bug. The codebase should not be convoluted, complexified, obfucated, altered, touched, or slowed down just prevent perverse, sadistic safe-cracking using this tool. The docs are clear on this subject: "Care must be taken when using objeccts returned by get_referrers() becasue some of them could still be under construction and hence in a temporarily invalid state. Avoid using get_referrers() for any purpose other than debugging." Raymond
On 7/10/06, Raymond Hettinger <rhettinger@ewtllc.com> wrote:
Right. That is on the list of crashers I am ignoring. The codebase should not be convoluted,
And I am trying to make sure all the fixes are not superfluous but fix actual issues in the code and behaviour of Python. -Brett
participants (2)
-
Brett Cannon -
Raymond Hettinger