Re: [Python-Dev] Any tips to tell sprinter at PyCon about developing on Windows?

2008-02-05 Thread Trent Nelson
Feb 2, 2008 7:34 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Brett Cannon wrote:
> > It would be really cool if you can recruit some experienced Windows
> > developers. :]
> That's the point in all of this. =)
> -Brett

I'll be around for the sprints -- didn't really have a plan as to what I'd like 
to sprint on but if there's some interest in farming Windows developers, I'll 
raise my hand.  Anything in particular you can point myself or others in the 
Windows camp at such that we're a bit better prepared come sprint time (i.e. 
open issues)?

(Also, I'm looking to acquire a new reasonably well-spec'd Windows box for 
work.  If it's available in time for PyCon, I should be able to set up a couple 
of virtual 64-bit Vista/Server 2008 images with VS 2008 dev environments that 
non-Windows developers could use, if that would be desirable.)

Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] XXX - in funcobject.c

2008-02-05 Thread Kristján Valur Jónsson
Hello there.

in function_call() in funcobject.c, we have this comment:

/* XXX This is broken if the caller deletes dict items! */

Now,  I wonder what specifically is meant here?  are we really talking about 
the 'callee' here?
In PyEval_EvalCodeEx() it looks as though all keywords are always INCREFed, so 
the callee never gets a borrowed reference to something from the keyword dict.

Maybe this comment is out of date, or can someone demonstrate how to break the 
code accordingly?

The reason I ask is that I am debugging a really tricky crash case on our live 
servers and I am currently led to believe that the temporary array for the 
keyword dict is being overwritten somehow.

Cheers,

Kristján,
CCP games.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] XXX - in funcobject.c

2008-02-05 Thread Guido van Rossum
I think we really *are* talking about the caller -- the caller owns
the dict, if it managed to delete something from the dict before the
callee can incref it, you'd have trouble. I don't immediately see how
this could happen, which is probably why I left it as an XXX
comment...

--Guido

On Feb 5, 2008 6:58 AM, Kristján Valur Jónsson <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hello there.
>
>
>
> in function_call() in funcobject.c, we have this comment:
>
>
>
> /* XXX This is broken if the caller deletes dict items! */
>
>
>
> Now,  I wonder what specifically is meant here?  are we really talking about
> the ‚callee' here?
>
> In PyEval_EvalCodeEx() it looks as though all keywords are always INCREFed,
> so the callee never gets a borrowed reference to something from the keyword
> dict.
>
>
>
> Maybe this comment is out of date, or can someone demonstrate how to break
> the code accordingly?
>
>
>
> The reason I ask is that I am debugging a really tricky crash case on our
> live servers and I am currently led to believe that the temporary array for
> the keyword dict is being overwritten somehow.
>
>
>
> Cheers,
>
>
>
> Kristján,
>
> CCP games.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] XXX - in funcobject.c

2008-02-05 Thread Amaury Forgeot d'Arc
Guido van Rossum wrote:
> I think we really *are* talking about the caller -- the caller owns
> the dict, if it managed to delete something from the dict before the
> callee can incref it, you'd have trouble. I don't immediately see how
> this could happen, which is probably why I left it as an XXX
> comment...

I found one way to call python code before the callee can incref the
args: the __eq__ between variable names and the dict entries. The
following snippet crashes the trunk version on win32:

class Name(str):
  def __eq__(self, other):
 del d[self]
 return str.__eq__(self, other)
  def __hash__(self):
 return str.__hash__(self)

d = {Name("a"):1, Name("b"):2}
def f(a, b): print a,b

f(**d)   # Segfault


There are several variants of this crasher; they all have more than
one keyword argument, and keywords strings must override __eq__ or
__hash__.
I could not find any other way to execute python code in this area.

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] XXX - in funcobject.c

2008-02-05 Thread Guido van Rossum
On Feb 5, 2008 2:07 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I think we really *are* talking about the caller -- the caller owns
> > the dict, if it managed to delete something from the dict before the
> > callee can incref it, you'd have trouble. I don't immediately see how
> > this could happen, which is probably why I left it as an XXX
> > comment...
>
> I found one way to call python code before the callee can incref the
> args: the __eq__ between variable names and the dict entries. The
> following snippet crashes the trunk version on win32:
>
> class Name(str):
>   def __eq__(self, other):
>  del d[self]
>  return str.__eq__(self, other)
>   def __hash__(self):
>  return str.__hash__(self)
>
> d = {Name("a"):1, Name("b"):2}
> def f(a, b): print a,b
>
> f(**d)   # Segfault
>
>
> There are several variants of this crasher; they all have more than
> one keyword argument, and keywords strings must override __eq__ or
> __hash__.
> I could not find any other way to execute python code in this area.

Thanks Amaury! Do you think it would be sufficient to change the
PyString_Check() call in PyEval_EvalCodeEx into a
PyString_CheckExact() call? Or is the proper fix to incref the values
going into the kw array and decref them upon exit?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] XXX - in funcobject.c

2008-02-05 Thread Amaury Forgeot d'Arc
Guido van Rossum wrote:
> Thanks Amaury! Do you think it would be sufficient to change the
> PyString_Check() call in PyEval_EvalCodeEx into a
> PyString_CheckExact() call?

This would prevent this "attack", but would remain fragile - future
developments could allow execution of python code somewhere.

> Or is the proper fix to incref the values
> going into the kw array and decref them upon exit?

Yet Another Kind Of Tuple... However this seems the correct thing to do.

In addition, if we agree to restrict arguments names to str (and
disallow subclasses), there are easy optimizations in
PyEval_EvalCodeEx, somewhere around the "XXX slow" comment (!)

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] XXX - in funcobject.c

2008-02-05 Thread Guido van Rossum
On Feb 5, 2008 4:02 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Thanks Amaury! Do you think it would be sufficient to change the
> > PyString_Check() call in PyEval_EvalCodeEx into a
> > PyString_CheckExact() call?
>
> This would prevent this "attack", but would remain fragile - future
> developments could allow execution of python code somewhere.
>
> > Or is the proper fix to incref the values
> > going into the kw array and decref them upon exit?
>
> Yet Another Kind Of Tuple... However this seems the correct thing to do.

Agreed.

> In addition, if we agree to restrict arguments names to str (and
> disallow subclasses), there are easy optimizations in
> PyEval_EvalCodeEx, somewhere around the "XXX slow" comment (!)

Do you think you have time to come up with a patch? If not, can you
file a bug for this so we won't forget?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com