Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Pausing or adding new breakpoints halfway during running in VSCode makes the Python Exception lost

オープン
  • 何か問題がありますか？
#1,913 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python, vscode
領域
devtools

調査の方向性

まず最小限の Python 例を実行し、VSCode の 3 つのフロー（Pause、あらかじめ設定したブレークポイント、実行中にブレークポイントを追加する場合）を再現します。結果として得られる例外処理、特に sys.settrace コールバックのメッセージを比較します。Pause と実行中に追加したブレークポイントが、あらかじめ設定したブレークポイントと同様に RuntimeError を捕捉し、プログラムが一時停止したままにならなければ完了です。

索引モデルが issue の本文から書いたものです。

説明

Environment data

  • debugpy version: 1.8.13
  • OS and version: Linux abc 5.15.0-139-generic #149 ~20.04.1-Ubuntu SMP Wed Apr 16 08:29:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
  • Python version (& distribution if applicable, e.g. Anaconda): Python 3.10.18 (miniconda 23.5.2)
  • Using VS Code or Visual Studio: VSCode

Actual behavior

Pausing or adding new breakpoints halfway during debugging in VSCode seems to make the Python Exception uncaught.

The following is a minimal example to reproduce my problem.

import contextlib, signal

@contextlib.contextmanager
def time_limit(seconds):
    def signal_handler(signum, frame):
        raise RuntimeError("Timed out!")

    signal.setitimer(signal.ITIMER_REAL, seconds)
    signal.signal(signal.SIGALRM, signal_handler)
    try:
        yield
    finally:
        signal.setitimer(signal.ITIMER_REAL, 0)
    

if __name__ == "__main__":
    print("start")
    try:
        with time_limit(10):
            a=1
            while True:
                a = -a
    except RuntimeError:
        print("timed out")
    print("finished")

Different ways of debugging will give different results:

  1. Use Pause. The exception is not caught. I click the pause (F6) halfway through running, and the program pauses on the line a=-a as expected. After several seconds, the time limit is reached, and the RuntimeError is thrown, but the program fails to catch the error. The trackback is printed in the console, but the program is not interrupted (still paused). As a result, the program will run forever after clicking continue (F5).

  2. Use preset breakpoint. The exception is caught. In contrast, if you set a breakpoint at the a=-a. Run the program, and the program will stop at the breakpoint. Wait a few seconds, and the program will catch the runtime error and finish successfully. The program will continue automatically once it receives the Exception without the user's permission, which is also strange to me.

  3. Add a breakpoint halfway. The exception is not caught. If you add a new breakpoint at a=-a after the program runs for a while, you can find the same behavior as "using Pause". In my opinion, "Pause" may be implemented by "adding a breakpoint halfway"? If this is correct, then this problem may be about "adding a breakpoint while running".

More experimental results:
When using Pause. After pausing, if I switch to the Debug Console, the following message will be thrown when the time limit is reached:

<class 'RuntimeError'> raised from within the callback set in sys.settrace.
Debugging will be disabled for this thread (<_MainThread(MainThread, started 140324903388352)>).

Expected behavior

I expect both 1(Use Pause) and 3(Add a breakpoint halfway) to behave similarly to 2(Use preset breakpoint).

Steps to reproduce:

  1. As stated in Actual behavior, just try to debug the code in three different ways.
主要言語
Python
スター
2.5k
フォーク
205
平均マージ
1日 3時間
マージ済み PR（30日）
5

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/debugpy のほかの issue

microsoft/debugpy の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。