php / php/php-src

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

Offen
#22,725 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Category: Engine Feature
Vorherrschende Sprache
C
Sterne
40.4k
Forks
8.2k
Ø Merge
2 T. 13 Std.
Gemergte PRs (30 T.)
96

Beschreibung

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

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit PHPs statischen exception__thrown- und exception__caught-Probes und vergleiche anschließend deren dokumentierte Argumente mit den in der Issue erwähnten function__entry/return-Probes. Ermittle, ob Dateiname, Zeilennummer, Nachricht und der Kontext der internen Generierung an jeder Probe verfügbar sind; abgeschlossen ist die Aufgabe mit einer Machbarkeitsentscheidung und, falls sie angenommen wird, einer definierten Änderung der Probe-Argumente und Dokumentation.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
c, php
Bereich
observability-sre
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.