[Python-Dev] segmentation fault in Python 2.5b3 (trunk:51066)

[Duncan Booth]

Thomas Heller <theller at python.net> wrote in
news:easvak$89h$1 at sea.gmane.org: 

>>      /* if no docstring given and the getter has one, use that one */
>>      if ((doc == NULL || doc == Py_None) && get != NULL && 
>>          PyObject_HasAttrString(get, "__doc__")) {
>>           if (!(get_doc = PyObject_GetAttrString(get, "__doc__")))
>>                return -1;
>>           Py_DECREF(get_doc); /* it is INCREF'd again below */
>>                 ^^^^^^^^^^^^^^^^^^
>>           doc = get_doc;
>>      }
>> 
>>      Py_XINCREF(get);
>>      Py_XINCREF(set);
>>      Py_XINCREF(del);
>>      Py_XINCREF(doc);
>> 
> 
> A strange programming style, if you ask me, and I wonder why Coverity
> doesn't complain about it.
> 
Does Coverity recognise objects on Python's internal pools as deallocated? 

If not it wouldn't complain because all that the Py_DECREF does is link the 
block into a pool's freeblock list so any subsequent reference from the 
Py_XINCREF is still a reference to allocated memory.


[Off topic:
Microsoft have (or had?) a similarly screwy bit in their ActiveX atl 
libraries: a newly created ActiveX object has its reference count 
incremented before calling FinalConstruct and then  decremented to 0  
(using a method which decrements the reference count but doesn't free it) 
before being incremented again. If in the meanwhile you increment and 
decrement the reference count in another thread then it goes bang.]

The moral is to regard the reference counting rules as law: no matter how 
sure you are that you can cheat, don't or you'll regret it.