AppPkg/Applications/Python: Add Python 2.7.2 sources since the release of Python 2.7.3 made them unavailable from the python.org web site.

These files are a subset of the python-2.7.2.tgz distribution from python.org.  Changed files from PyMod-2.7.2 have been copied into the corresponding directories of this tree, replacing the original files in the distribution.

Signed-off-by: daryl.mcdaniel@intel.com


git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13197 6f19259b-4bc3-4df7-8a09-765794883524
This commit is contained in:
darylm503
2012-04-16 22:12:42 +00:00
parent cbc6b5e545
commit 4710c53dca
2106 changed files with 871583 additions and 0 deletions

View File

@@ -0,0 +1,16 @@
This directory only contains tests for outstanding bugs that cause the
interpreter to segfault. Ideally this directory should always be empty, but
sometimes it may not be easy to fix the underlying cause and the bug is deemed
too obscure to invest the effort.
Each test should fail when run from the command line:
./python Lib/test/crashers/weakref_in_del.py
Put as much info into a docstring or comments to help determine the cause of the
failure, as well as a bugs.python.org issue number if it exists. Particularly
note if the cause is system or environment dependent and what the variables are.
Once the crash is fixed, the test case should be moved into an appropriate test
(even if it was originally from the test suite). This ensures the regression
doesn't happen again. And if it does, it should be easier to track down.

View File

@@ -0,0 +1,19 @@
"""
Broken bytecode objects can easily crash the interpreter.
This is not going to be fixed. It is generally agreed that there is no
point in writing a bytecode verifier and putting it in CPython just for
this. Moreover, a verifier is bound to accept only a subset of all safe
bytecodes, so it could lead to unnecessary breakage.
For security purposes, "restricted" interpreters are not going to let
the user build or load random bytecodes anyway. Otherwise, this is a
"won't fix" case.
"""
import types
co = types.CodeType(0, 0, 0, 0, '\x04\x71\x00\x00', (),
(), (), '', '', 1, '')
exec co

View File

@@ -0,0 +1,29 @@
"""
_PyType_Lookup() returns a borrowed reference.
This attacks the call in dictobject.c.
"""
class A(object):
pass
class B(object):
def __del__(self):
print 'hi'
del D.__missing__
class D(dict):
class __missing__:
def __init__(self, *args):
pass
d = D()
a = A()
a.cycle = a
a.other = B()
del a
prev = None
while 1:
d[5]
prev = (prev,)

View File

@@ -0,0 +1,38 @@
"""
_PyType_Lookup() returns a borrowed reference.
This attacks PyObject_GenericSetAttr().
NB. on my machine this crashes in 2.5 debug but not release.
"""
class A(object):
pass
class B(object):
def __del__(self):
print "hi"
del C.d
class D(object):
def __set__(self, obj, value):
self.hello = 42
class C(object):
d = D()
def g():
pass
c = C()
a = A()
a.cycle = a
a.other = B()
lst = [None] * 1000000
i = 0
del a
while 1:
c.d = 42 # segfaults in PyMethod_New(im_func=D.__set__, im_self=d)
lst[i] = c.g # consume the free list of instancemethod objects
i += 1

View File

@@ -0,0 +1,5 @@
"""
The compiler (>= 2.5) recurses happily.
"""
compile('()'*9**5, '?', 'exec')

View File

@@ -0,0 +1,36 @@
"""
The gc module can still invoke arbitrary Python code and crash.
This is an attack against _PyInstance_Lookup(), which is documented
as follows:
The point of this routine is that it never calls arbitrary Python
code, so is always "safe": all it does is dict lookups.
But of course dict lookups can call arbitrary Python code.
The following code causes mutation of the object graph during
the call to has_finalizer() in gcmodule.c, and that might
segfault.
"""
import gc
class A:
def __hash__(self):
return hash("__del__")
def __eq__(self, other):
del self.other
return False
a = A()
b = A()
a.__dict__[b] = 'A'
a.other = b
b.other = a
gc.collect()
del a, b
gc.collect()

View File

@@ -0,0 +1,32 @@
"""
gc.get_referrers() can be used to see objects before they are fully built.
Note that this is only an example. There are many ways to crash Python
by using gc.get_referrers(), as well as many extension modules (even
when they are using perfectly documented patterns to build objects).
Identifying and removing all places that expose to the GC a
partially-built object is a long-term project. A patch was proposed on
SF specifically for this example but I consider fixing just this single
example a bit pointless (#1517042).
A fix would include a whole-scale code review, possibly with an API
change to decouple object creation and GC registration, and according
fixes to the documentation for extension module writers. It's unlikely
to happen, though. So this is currently classified as
"gc.get_referrers() is dangerous, use only for debugging".
"""
import gc
def g():
marker = object()
yield marker
# now the marker is in the tuple being constructed
[tup] = [x for x in gc.get_referrers(marker) if type(x) is tuple]
print tup
print tup[1]
tuple(g())

View File

@@ -0,0 +1,16 @@
# This was taken from http://python.org/sf/1541697
# It's not technically a crasher. It may not even truly be infinite,
# however, I haven't waited a long time to see the result. It takes
# 100% of CPU while running this and should be fixed.
import re
starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*('
r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]'
r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?'
r')*\s*/?\s*(?=[<>])')
if __name__ == '__main__':
foo = '<table cellspacing="0" cellpadding="0" style="border-collapse'
starttag.match(foo)

View File

@@ -0,0 +1,35 @@
"""
There is a way to put keys of any type in a type's dictionary.
I think this allows various kinds of crashes, but so far I have only
found a convoluted attack of _PyType_Lookup(), which uses the mro of the
type without holding a strong reference to it. Probably works with
super.__getattribute__() too, which uses the same kind of code.
"""
class MyKey(object):
def __hash__(self):
return hash('mykey')
def __cmp__(self, other):
# the following line decrefs the previous X.__mro__
X.__bases__ = (Base2,)
# trash all tuples of length 3, to make sure that the items of
# the previous X.__mro__ are really garbage
z = []
for i in range(1000):
z.append((i, None, None))
return -1
class Base(object):
mykey = 'from Base'
class Base2(object):
mykey = 'from Base2'
# you can't add a non-string key to X.__dict__, but it can be
# there from the beginning :-)
X = type('X', (Base,), {MyKey(): 5})
print X.mykey
# I get a segfault, or a slightly wrong assertion error in a debug build.

View File

@@ -0,0 +1,31 @@
# The cycle GC collector can be executed when any GC-tracked object is
# allocated, e.g. during a call to PyList_New(), PyDict_New(), ...
# Moreover, it can invoke arbitrary Python code via a weakref callback.
# This means that there are many places in the source where an arbitrary
# mutation could unexpectedly occur.
# The example below shows list_slice() not expecting the call to
# PyList_New to mutate the input list. (Of course there are many
# more examples like this one.)
import weakref
class A(object):
pass
def callback(x):
del lst[:]
keepalive = []
for i in range(100):
lst = [str(i)]
a = A()
a.cycle = a
keepalive.append(weakref.ref(a, callback))
del a
while lst:
keepalive.append(lst[:])

View File

@@ -0,0 +1,47 @@
# from http://mail.python.org/pipermail/python-dev/2001-June/015239.html
# if you keep changing a dictionary while looking up a key, you can
# provoke an infinite recursion in C
# At the time neither Tim nor Michael could be bothered to think of a
# way to fix it.
class Yuck:
def __init__(self):
self.i = 0
def make_dangerous(self):
self.i = 1
def __hash__(self):
# direct to slot 4 in table of size 8; slot 12 when size 16
return 4 + 8
def __eq__(self, other):
if self.i == 0:
# leave dict alone
pass
elif self.i == 1:
# fiddle to 16 slots
self.__fill_dict(6)
self.i = 2
else:
# fiddle to 8 slots
self.__fill_dict(4)
self.i = 1
return 1
def __fill_dict(self, n):
self.i = 0
dict.clear()
for i in range(n):
dict[i] = i
dict[self] = "OK!"
y = Yuck()
dict = {y: "OK!"}
z = Yuck()
y.make_dangerous()
print dict[z]

View File

@@ -0,0 +1,16 @@
# The following example may crash or not depending on the platform.
# E.g. on 32-bit Intel Linux in a "standard" configuration it seems to
# crash on Python 2.5 (but not 2.4 nor 2.3). On Windows the import
# eventually fails to find the module, possibly because we run out of
# file handles.
# The point of this example is to show that sys.setrecursionlimit() is a
# hack, and not a robust solution. This example simply exercises a path
# where it takes many C-level recursions, consuming a lot of stack
# space, for each Python-level recursion. So 1000 times this amount of
# stack space may be too much for standard platforms already.
import sys
if 'recursion_limit_too_high' in sys.modules:
del sys.modules['recursion_limit_too_high']
import recursion_limit_too_high

View File

@@ -0,0 +1,15 @@
#!/usr/bin/env python
# No bug report AFAIK, mail on python-dev on 2006-01-10
# This is a "won't fix" case. It is known that setting a high enough
# recursion limit crashes by overflowing the stack. Unless this is
# redesigned somehow, it won't go away.
import sys
sys.setrecursionlimit(1 << 30)
f = lambda f:f(f)
if __name__ == '__main__':
f(f)