[Patches] [ python-Patches-784825 ] fix obscure crash in descriptor handling

SourceForge.net noreply at sourceforge.net
Fri Aug 15 07:11:01 EDT 2003


Patches item #784825, was opened at 2003-08-07 16:32
Message generated for change (Settings changed) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470

Category: Core (C code)
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: fix obscure crash in descriptor handling

Initial Comment:
Ages & ages back twouters pointed out a potential hole in 
PyObject_GenericGetAttr.  I've come up with a testcase & a 
fix, attached to this report.

Are there any other bits of code shaped like 
PyObject_GenericGetAttr?  I've fixed type_getattro.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-15 14:10

Message:
Logged In: YES 
user_id=6656

Thanks for spending the brain cells on this!

Checked in as:

Objects/object.c revision 2.210
Objects/typeobject.c revision 2.244
Lib/test/test_descr.py revision 1.198

A large part of the obscurity in PyObject_GenericGetAttr
comes from the inlining of _PyType_Lookup &
PyObject_GetDictPtr.  I really hope that it's worth it...

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-15 05:33

Message:
Logged In: YES 
user_id=80475

P.S.  It's not your code that's unclear; rather, the whole 
function is a nest of interdependencies, cyclomatic 
complexities, and too much activity between setting a state 
and something that depends on the state.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-14 20:48

Message:
Logged In: YES 
user_id=80475

This code in the section is as clear as mud.  After several 
tries, I was able to see why the XDECREF was not needed.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-12 11:21

Message:
Logged In: YES 
user_id=6656

First two comments: thanks, I've uploaded a new version with
these taken on board.

> In object.c, the DECREF on line 1459 should be a XDECREF 

No.  Look where f came from.

> and the final exit path (running PyErr_Format) also needs a 
> XDECREF.

I object to putting in Py_XDECREF(foo) when I know foo ==
NULL.  Or am I missing something? (this same applies to the
similar comment about typeobject.c).

> This is labelled as a Py2.4 patch but it should probably be 
> backported also.

Oh yes, this applies to 2.3 and almost surely 2.2, too.

Back to you.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-12 01:36

Message:
Logged In: YES 
user_id=80475

In typeobject.c, eliminate the else-block so that it is obvious 
that the incref always gets executed before the block ends.

Also, the first XDECREF (on line 2022) needs to be 
repositioned (to later in the block) because, in MSVC++, the 
descrgetfunc declaration (two lines below) needs to be the 
first line in the code block.

The final exit path (marked "give up") also need a DECREF.

In object.c, the DECREF on line 1459 should be a XDECREF 
and the final exit path (running PyErr_Format) also needs a 
XDECREF.

This is labelled as a Py2.4 patch but it should probably be 
backported also.



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-11 18:42

Message:
Logged In: YES 
user_id=6656

trying to attach again, grr

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-08-11 18:38

Message:
Logged In: YES 
user_id=6656

upload new patch that has a test that doesn't call gc.get_referrers 
on the integer 1 and thus create uncollectable cycles (or 
something like that, anyway).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=784825&group_id=5470



More information about the Patches mailing list