[Python-Dev] CALL_ATTR patch (was: 2.3b1 release) (original) (raw)
Guido van Rossum guido@python.org
Thu, 17 Apr 2003 20:22:56 -0400
- Previous message: [Python-Dev] CALL_ATTR patch (was: 2.3b1 release)
- Next message: [Python-Dev] CALL_ATTR patch
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
(Looking at PyObjectGenericGetAttr with that in mind, I wonder if there isn't a possible crash there. In the first MRO lookup, looking for descr's, if a non-data-descr is found, it is kept around but not INCREF'd until later, after the instance-dict is searched. Am I wrong in believing the PyDictGetItem of the instance dict can call Python code ?
It can, if there's a key whose type has a custom eq or cmp. So indeed, if this custom eq is evil enough to delete the corresponding key from the class dict, it could cause descr to point to freed memory. I won't try to construct a case, but it's not impossible. :-(
Fixing this would make the code even hairier though... :-(
There isn't even as much as an assert(PyDictCheck(dict)) there.)
All over the place it is assumed and ensured that a types tp_dict and an instance's dict are always real dicts. The only way this could be violated would be by C code defining a type that violates this.
--Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] CALL_ATTR patch (was: 2.3b1 release)
- Next message: [Python-Dev] CALL_ATTR patch
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]