dtrace probes exception__caught , exception__thrown useless without more probe arguments for context
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
調査の方向性
PHP の exception__thrown と exception__caught の静的プローブから始め、次に、それらの文書化された引数を issue で言及されている function__entry/return プローブと比較します。各プローブでファイル名、行番号、メッセージ、内部生成コンテキストが利用可能かどうかを確認します。完了とは、実現可能性の判断を行い、受け入れる場合はプローブの引数とドキュメントに対する変更を定義することです。
索引モデルが issue の本文から書いたものです。
説明
Description
c.f https://www.php.net/manual/en/features.dtrace.dtrace.php
Why do the two static "exception" probes of PHP (i.e. "exception__caught" and "exception_thrown" ) offer only a single probe argument which is the exception-classname (i.e. char *classname)?
Is it some technical reason caused by the way the PHP interpreter works, or some non-technical reason? Can anyone remember the background for this?
Is it technically feasible to alter the PHP interpreter to provide additional probe-parameters specifically for both exception__thrown, and exception__caught probes? Specifically I want to see the filename, the line-number, and the exception-message if they are available, or an indicator that the exception is internally generated by PHP-interpreter.
I've been using the PHP probes with systemtap on ubuntu 24.04 and I've built PHP 8.5.8 for dtrace etc.
My use case is probing an Apache2 Wordpress site that has scores of Wordpress-plugins, at least one of which uses set_exception_handler(). Without changing any of the application code and without changing any Wordpress-plugins, I wanted to use systemtap to observe the PHP exceptions in more detail. Apache2 is the sole process using PHP, and Apache2 is serving only a single website. I used systemtap (instead of eBPF or dtrace) because I previously used it for other non PHP stuff also - although I understand all these interfaces use the same static probe points of PHP.
It is particularly useful that the other PHP probes for function__entry/return, and request__startup/return etc all offer additional probe-parameters such as the filename, line-number etc, but these incur a runtime performance-penalty which the exception-probes will not incur as exceptions rarely get thrown.
But for some reason the PHP "exception__caught" and "exception__thrown" probes only offer "ClassName" as the sole probe-parameter. In my experience that classname is almost always exactly "Exception" for the "exception__thrown" probe, which is unhelpful! It would be much more helpful if the two PHP exception-probes additionally offered the filename, the line-number, the exception-message (if all those are available, of course), specifically so that I can reconcile the "thrown" and the "caught" exceptions, plus for any thrown exceptions to also see the origin (filename + line-number, or some indication that the exception is internally generated by PHP interpreter (e.g. UnWindExit).
- 主要言語
- C
- スター
- 40.4k
- フォーク
- 8.2k
- 平均マージ
- 2日 15時間
- マージ済み PR(30日)
- 103
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
php/php-src のほかの issue
-
Bug SAPI: cli_server Status: Verified
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
Bug Status: Needs Triage
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
Bug Status: Needs Triage
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
-
Bug Status: Needs Triage
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
Bug Category: Tests Status: Verified
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
zephyrproject-rtos/zephyr#119726 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
api7/lua-resty-saml#63 ·
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
BasedHardware/omi#15320 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
FujiNetWIFI/fujinet-firmware#1649 · コメント 2 件 ·