php / php/php-src

dtrace probes exception__caught , exception__thrown useless without more probe arguments for context

Open
#22,725 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Category: Engine Feature
Dominant language
C
Stars
40.4k
Forks
8.1k
Avg merge
2d 13h
Merged PRs (30d)
96

Description

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).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with PHP's exception__thrown and exception__caught static probes, then compare their documented arguments with the function__entry/return probes mentioned in the issue. Determine whether filename, line number, message, and internal-generation context are available at each probe; done means a feasibility decision and, if accepted, a defined change to the probe arguments and documentation.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, php
Domain
observability-sre
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.