The code is also simple on this one:
from types import CodeType as code
exec code(0, 2, 3, 0, "lol lolol", (), (), (), "", "", 0, "") 

The interpreter isn't checking if the code object is correct, therefore it is possible to segfault by putting wrong opcodes and more.

Why are you even using v2.7 anyway when you can use asyncio with the coroutines in 3.4 or newer (which is pretty fast on things and is thread safe).

Can recreate on both py2.7 and py3.6

Constructor for CodeType in py3.6 is slightly different:

exec(code(0, 0, 2, 3, 0, b"lol lolol", (), (), (), "", "", 0, b""))

I can also reproduce on 3.5 and on 3.4.
Thank you.

I don't think this is a bug.  You can construct whatever code object you like; it is your responsibility at that point to make sure it is correct.  This is an example of why we call Python a "consenting adults" language.

I agree with RDM. CPython makes no guarantee that you can't crash the interpreter if you really try to.  "Consenting adult" means we don't impose performance penalties on everyone just to protect some users from their own attempts to exploit edge cases.

Let me add that, in principle, no one is opposed to making Python more fault-tolerant, certainly if there are demonstrable cases where the behavior can be exploited to deny services to others.  Cases like this, where it would seem that exploiters could only deny service to themselves, are much less interesting.  If someone were to submit a patch with tests and with benchmarking to show that the fix has minimal performance implications, a core developer might be inclined to review it.  But that seems like a lot of work for little gain when there are far more important problems that need attention.  Hence "consenting adults".

I do agree it is not a very big problem, but it is still a problem. If a python program took user input (maybe HTTP server) took user input (POST values) and construct a code object with that input. It would be possible to crash it and that can be bad for the web application. Even though it is not the most important Python problem, it is still a problem which can cause moderate problems, and it can be exploited remotely if the HTTP server did what I said before. One vulnerable HTTP server is one too many ;)
Hope it helps :)

If you construct a code object with user input without a checking, the segfault is the least of your problems. The user can inject a code that formats your hard disk or steals your passwords. It is impossible to write general checker that accepts all legitimate bytecode, but rejects malicious bytecode.

Yes, but it is possible to blacklist some bytecode (it may be possible to blacklist all or almost all malicious bytecode) and even more if the attacker just wants to crash the target then the segfault would be an easy crash. It is still an attack scenario that is possible.
Hope it helps :)