gh-98894: Fix dtrace tests in shared builds - #153372
Conversation
|
cc @vstinner |
Generate SystemTap probe definitions targeting libpython for shared builds and use centralized USDT probe object discovery for readelf and BPFTrace.
|
Rebased to fix conflicts |
|
Python configured with: Without the change, I get: |
|
The systemtap tests require the same kernel-devel package as the running kernel, if it's not there the test will be skipped. |
|
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. |
This reverts commit 9d87605.
|
Should be backported on 3.15 as well. |
Generate SystemTap probe definitions targeting libpython for shared builds and use centralized USDT probe object discovery for readelf and BPFTrace.
|
Thanks @stratakis for the PR, and @vstinner for merging it 🌮🎉.. I'm working now to backport this PR to: 3.15. |
|
GH-155803 is a backport of this pull request to the 3.15 branch. |
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).