3 files changed, 99 insertions, 0 deletions
diff --git a/Lib/test/crashers/bogus_sre_bytecode.py b/Lib/test/crashers/bogus_sre_bytecode.py
new file mode 100644
index 0000000..4bfc730
--- /dev/null
+++ b/Lib/test/crashers/bogus_sre_bytecode.py
@@ -0,0 +1,47 @@
+"""
+The regular expression engine in '_sre' can segfault when interpreting
+bogus bytecode.
+
+It is unclear whether this is a real bug or a "won't fix" case like
+bogus_code_obj.py, because it requires bytecode that is built by hand,
+as opposed to compiled by 're' from a string-source regexp.  The
+difference with bogus_code_obj, though, is that the only existing regexp
+compiler is written in Python, so that the C code has no choice but
+accept arbitrary bytecode from Python-level.
+
+The test below builds and runs random bytecodes until 'match' crashes
+Python.  I have not investigated why exactly segfaults occur nor how
+hard they would be to fix.  Here are a few examples of 'code' that
+segfault for me:
+
+    [21, 50814, 8, 29, 16]
+    [21, 3967, 26, 10, 23, 54113]
+    [29, 23, 0, 2, 5]
+    [31, 64351, 0, 28, 3, 22281, 20, 4463, 9, 25, 59154, 15245, 2,
+                  16343, 3, 11600, 24380, 10, 37556, 10, 31, 15, 31]
+
+Here is also a 'code' that triggers an infinite uninterruptible loop:
+
+    [29, 1, 8, 21, 1, 43083, 6]
+
+"""
+
+import _sre, random
+
+def pick():
+    n = random.randrange(-65536, 65536)
+    if n < 0:
+        n &= 31
+    return n
+
+ss = ["", "world", "x" * 500]
+
+while 1:
+    code = [pick() for i in range(random.randrange(5, 25))]
+    print code
+    pat = _sre.compile(None, 0, code)
+    for s in ss:
+        try:
+            pat.match(s)
+        except RuntimeError:
+            pass
diff --git a/Lib/test/crashers/infinite_loop_re.py b/Lib/test/crashers/infinite_loop_re.py
new file mode 100644
index 0000000..9aecc56
--- /dev/null
+++ b/Lib/test/crashers/infinite_loop_re.py
@@ -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)
diff --git a/Lib/test/crashers/loosing_mro_ref.py b/Lib/test/crashers/loosing_mro_ref.py
new file mode 100644
index 0000000..f0b8047
--- /dev/null
+++ b/Lib/test/crashers/loosing_mro_ref.py
@@ -0,0 +1,36 @@
+"""
+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'
+
+class X(Base):
+    # you can't add a non-string key to X.__dict__, but it can be
+    # there from the beginning :-)
+    locals()[MyKey()] = 5
+
+print X.mykey
+# I get a segfault, or a slightly wrong assertion error in a debug build.