Uh oh!
There was an error while loading. Please reload this page.
gh-98894: Fix dtrace tests in shared builds - #153372
Conversation
stratakis
commented
Jul 8, 2026
cc @vstinner |
Generate SystemTap probe definitions targeting libpython for shared builds and use centralized USDT probe object discovery for readelf and BPFTrace.
stratakis
commented
Jul 9, 2026
Rebased to fix conflicts |
vstinner
commented
Jul 13, 2026
Python configured with: Without the change, I get: |
stratakis
commented
Jul 13, 2026
The systemtap tests require the same kernel-devel package as the running kernel, if it's not there the test will be skipped. |
vstinner
commented
Aug 6, 2026
I tested again the change. Python built with Without the change: With the change: So we get: "Total tests: run=3 skipped=6" => "Total tests: run=9 skipped=4". 6 more tests are run thanks to the change. With the change, BPFTraceNormalTests and BPFTraceOptimizedTests tests are run. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
This reverts commit 9d87605.
Uh oh!
There was an error while loading. Please reload this page.
When Python is configured with --with-dtrace and --enable-shared, its USDT probes are in libpython, not the executable. The SystemTap and BPFTrace backends in test_dtrace were searching the executable, causing the tests to fail or time out. This PR makes both backends target the object containing the probes. Static builds are unaffected.
On Fedora, this can be reproduced by running test_dtrace for BPFTrace as sudo and for SystemTap either as sudo or as a user in the stapusr and stapdev groups.
Also added a commit to truncate the output of the tools as it can be quite verbose when it errors out (you can inspect by running the same tests without sudo).