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 2011年10月08日 05:15 by rmtew, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| ast.diff | rmtew, 2011年10月08日 05:15 | review | ||
| Messages (2) | |||
|---|---|---|---|
| msg145158 - (view) | Author: (rmtew) | Date: 2011年10月08日 05:15 | |
Platform Windows 7. hg id: a3f2dba93743+ (3.2) I do not know any reproduction steps for this bug outside as a side-effect within an incomplete and problematic Stackless merge. This bug also seems to exist in cpython, and is not in Stackless specific code. It seems to be bad exception handling, but maybe I do not understand all cases where this code is used. 1. ast_error_finish is called. 2. It calls PyErr_Fetch(&type, &value, &tback); 3. It them proceeds to treat 'value' as a tuple which results in PyErr_BadInternalCall being called and then being used in place of the original exception. Reproduction steps: 1. Sync http://hg.python.org/stackless. 2. Update to 3.2-slp branch. 3. Merge in changes from v3.2.1 to v3.2.2. 4. Compile and run regression tests. 5. Several exceptions will happen along the lines of bad argument where ast exceptions have happened and hit the problem above. |
|||
| msg145159 - (view) | Author: (rmtew) | Date: 2011年10月08日 05:31 | |
False alarm, must have reproduced this in wrong source tree :-( Purely Stackless-specific. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:22 | admin | set | github: 57338 |
| 2011年10月08日 05:31:44 | rmtew | set | status: open -> closed resolution: not a bug messages: + msg145159 |
| 2011年10月08日 05:15:47 | rmtew | create | |