summaryrefslogtreecommitdiffstats
path: root/AppPkg/Applications/Python/Python-2.7.2/Lib/test/crashers/bogus_code_obj.py
diff options
context:
space:
mode:
Diffstat (limited to 'AppPkg/Applications/Python/Python-2.7.2/Lib/test/crashers/bogus_code_obj.py')
-rw-r--r--AppPkg/Applications/Python/Python-2.7.2/Lib/test/crashers/bogus_code_obj.py19
1 files changed, 19 insertions, 0 deletions
diff --git a/AppPkg/Applications/Python/Python-2.7.2/Lib/test/crashers/bogus_code_obj.py b/AppPkg/Applications/Python/Python-2.7.2/Lib/test/crashers/bogus_code_obj.py
new file mode 100644
index 0000000000..65968f14d3
--- /dev/null
+++ b/AppPkg/Applications/Python/Python-2.7.2/Lib/test/crashers/bogus_code_obj.py
@@ -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