Message346271
| Author |
Delgan |
| Recipients |
Delgan, ned.deily |
| Date |
2019年06月22日.08:12:38 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1561191159.13.0.68704919134.issue37365@roundup.psfhosted.org> |
| In-reply-to |
| Content |
Thanks to your answer, @ned.deily.
Sorry to insist, but are you sure this is a duplicate of issue18075 / issue35542?
According to the discussion in issue36272, it seems this is not related to stack exhaustion nor to issue18075.
Also, @remi.lapeyre suggested that a fix could be possible by modifying ceval.c. (re-raise RecursionError if it has been cleared).
issue18075 and issue35542 are both of status "closed", I would expect this issue to be duplicate to an "open" issue because there is a clear reproducible "bug" which crashes the interpreter.
There is also the problems still remaining in logging Handlers that I linked.
I think this is an issue with how recursion error are handled in ceval.c, this is related to "tstate->overflowed" and "tstate->recursion_depth > recursion_limit + 50".
If I understand correctly, this is implemented like this to allow gracefully catch and handle RecursionError from the calling function.
For example, why not re-raise the exception if the first one could not be handled correctly? |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2019年06月22日 08:12:39 | Delgan | set | recipients:
+ Delgan, ned.deily |
| 2019年06月22日 08:12:39 | Delgan | set | messageid: <1561191159.13.0.68704919134.issue37365@roundup.psfhosted.org> |
| 2019年06月22日 08:12:39 | Delgan | link | issue37365 messages |
| 2019年06月22日 08:12:38 | Delgan | create |
|