➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2013-02-11 23:54 by larry, last changed 2022-04-11 14:57 by admin. 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) *  |
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) * |
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) * |
Date: 2017-06-22 14:54 | |
I suggest to close this issue as "not a bug" or "wont fix". |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:57:41 | admin | set | github: 61389 |
| 2017-06-23 05:35:25 | benjamin.peterson | set | status: pending -> closed resolution: not a bug stage: needs patch -> resolved |
| 2017-06-22 14:54:00 | serhiy.storchaka | set | status: open -> pending nosy: + serhiy.storchaka messages: + msg296635 |
| 2013-02-15 22:22:17 | terry.reedy | set | nosy:
+ terry.reedy |
| 2013-02-12 15:10:07 | benjamin.peterson | set | nosy:
+ benjamin.peterson messages: + msg181963 |
| 2013-02-12 12:55:49 | Ramchandra Apte | set | nosy:
+ Ramchandra Apte messages: + msg181953 |
| 2013-02-11 23:55:15 | larry | set | files:
+ lch.bandaid.for.malformed.fn.crash.1.patch keywords: + patch |
| 2013-02-11 23:54:43 | larry | create | |