Exceptions raised while tracing certain statements cannot be caught
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Bug report
So I found a really odd bug today. except blocks don't catch exceptions raised when tracing certain statements that themselves "cannot raise". For example:
def f():
breakpoint()
try:
pass # If you raise while tracing this line, the exception isn't caught.
except:
...
try:
42 # Ditto.
except:
...
try:
return # Ditto.
except:
...
A couple of observations:
- Exceptions raised while tracing other "normal" statements are handled the normal way.
- The code for the exception handling is still present in these examples, even though it's statically unreachable.
- If two or more of these "non-raising" statements occur together in the same block (like several
passstatements in a row), only the last one will have the bug:
def f():
breakpoint()
try:
pass # No bug
pass # No bug
pass # Bug
except:
...
I haven't invested any time into figuring out what the root cause is, I've just been poking at it with code examples. It's definitely a bug in the bytecode compiler though, not the interpreter (dis shows missing exception table entries). Probably something to do with how we emit exception tables for NOP or anything that unwinds the block stack, if I had to guess?
(This also affects 3.12, and maybe even earlier versions, but only tagging for 3.13 and newer since I don't think this is a "security" issue.)
Linked PRs
- gh-148333
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
issue の例を再現し、その dis 出力を調べ、pass、42、return に対する欠落した例外テーブルエントリに注目してください。これらのケースを通常の文のトレースと比較し、コンパイラによる NOP の処理とブロックスタックのアンワインドを調べてください。完了条件は、これらの文のトレース中に発生した例外を except ブロックが捕捉し、説明されているケースに対する回帰テストのカバレッジがあることです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- compilers
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100