classification
Title: Python segfaults from improperly formed and called function
Type: crash Stage: resolved
Components: Interpreter Core Versions: Python 3.3, Python 3.4
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Ramchandra Apte, benjamin.peterson, larry, serhiy.storchaka, terry.reedy
Priority: normal Keywords: 3.3regression, patch

Created on 2013-02-11 23:54 by larry, last changed 2017-06-23 05:35 by benjamin.peterson. This issue is now closed.

Files
File name Uploaded Description Edit
crashy.py larry, 2013-02-11 23:54 Example script that crashes Python 3.3.0 and trunk.
lch.bandaid.for.malformed.fn.crash.1.patch larry, 2013-02-11 23:55 Ill-concieved patch that makes the problem go away. Don't check it in! review
Messages (4)
msg181936 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2013-02-11 23:54
Python 3.3 added a nice new feature: if you don't supply enough positional parameters to a function, it tells you the names of the positional parameters you omitted.

Unfortunately, the code that prints this error message assumes that the function is well-formed.  If I manually create a function using types.CodeType and types.FunctionType, and I don't provide enough entries in the types.CodeType  "varnames" parameter to satisfy all the positional parameters, and I call the resulting function with insufficient parameters, Python crashes.

I've attached a sample script that demonstrates this crash.  I can reproduce it with both 3.3.0 and a recent trunk.  Since this feature wasn't in 3.2 or before, the bug doesn't seem to exist in those versions; I couldn't reproduce with 3.2 or 2.7.

The crash occurs in missing_arguments() in Python/ceval.c, line 3256 in trunk.  The function calls PyTuple_GET_ITEM on the co_varnames tuple without checking that it has sufficient entries.  It gets a crazytown pointer, calls PyObject_Repr on it, and boom.

I've attached a band-aid patch which prevents the crash, but this is almost certainly not the fix we want.  Perhaps types.CodeType should refuse to generate the malformed code object in the first place?
msg181953 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-02-12 12:55
> Perhaps types.CodeType should refuse to generate the malformed code object in the first place?
Yup.
msg181963 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2013-02-12 15:10
In general, you can generate whatever junky bytecode you want, and the eval loop will happy crash itself. Your on your own when screwing with types.CodeType.
msg296635 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-06-22 14:54
I suggest to close this issue as "not a bug" or "wont fix".
History
Date User Action Args
2017-06-23 05:35:25benjamin.petersonsetstatus: pending -> closed
resolution: not a bug
stage: needs patch -> resolved
2017-06-22 14:54:00serhiy.storchakasetstatus: open -> pending
nosy: + serhiy.storchaka
messages: + msg296635

2013-02-15 22:22:17terry.reedysetnosy: + terry.reedy
2013-02-12 15:10:07benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg181963
2013-02-12 12:55:49Ramchandra Aptesetnosy: + Ramchandra Apte
messages: + msg181953
2013-02-11 23:55:15larrysetfiles: + lch.bandaid.for.malformed.fn.crash.1.patch
keywords: + patch
2013-02-11 23:54:43larrycreate