Created on 2014-07-12 16:31 by anselm.kruis, last changed 2018-10-26 08:14 by serhiy.storchaka. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| crash_on_f_restricted.py | anselm.kruis, 2014-07-12 16:31 | test programm that eventually causes a crash | ||
| Messages (2) | |||
|---|---|---|---|
| msg222852 - (view) | Author: Anselm Kruis (anselm.kruis) * | Date: 2014-07-12 16:31 | |
If you store a reference to a frame from a dead thread and then access frame.f_restricted python eventually crashed. I didn't investigate this bug in depth. Here is my preliminary explanation. The access of frame.f_restricted causes a call of PyFrame_IsRestricted(f). PyFrame_IsRestricted is a macro and expands to ((f)->f_builtins != (f)->f_tstate->interp->builtins) Now, if the thread that created f is already dead, the f_tstate points to an invalid structure. Depending on the content of the memory the access of f_tstate->interp causes an access violation. I use a Win32 debug build to reliable reproduce the issue. |
|||
| msg328521 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2018-10-26 08:14 | |
Thank you for your report Anselm. Seems this bug is fixed in issue22851. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2018-10-26 08:14:40 | serhiy.storchaka | set | status: open -> closed superseder: 2.7 core crashes with generator.gi_frame.f_restricted nosy: + serhiy.storchaka messages: + msg328521 resolution: duplicate stage: resolved |
| 2014-07-12 16:31:09 | anselm.kruis | create | |