Bug 2027683
| Summary: | python tapset regression | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Martin Cermak <mcermak> |
| Component: | systemtap | Assignee: | Frank Ch. Eigler <fche> |
| systemtap sub component: | system-version | QA Contact: | Martin Cermak <mcermak> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | fche, lbalhar, lberk, mcermak, mjw, pviktori, torsava |
| Version: | 9.0 | Keywords: | Triaged |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemtap-4.6-8.el9 | Doc Type: | No Doc Update |
| Doc Text: |
If this bug requires documentation, please select an appropriate Doc Type value.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-17 13:27:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Deadline: | 2021-12-27 | ||
|
Description
Martin Cermak
2021-11-30 12:54:06 UTC
This file was never provided for python3. We can add it downstream, but we're only comfortable adding it if we can test it. AFAIK, it wasn't tested before. Could you provide some instructions on how this file can be tested? On further investigation, /usr/share/systemtap/tapset/python3.stp exists in RHEL; it's provided by systemtap-client. Is that the file you're looking for? If not, since systemtap-client is already providing Python integration, shouldn't it provide this file as well? (In reply to Petr Viktorin from comment #3) > On further investigation, /usr/share/systemtap/tapset/python3.stp exists in > RHEL; it's provided by systemtap-client. > Is that the file you're looking for? Nope. What I'm missing is a trivial tapset file defining the python.function.entry and python.function.return probes. On my rhel9 test system, that file would look like this: ====== 8< ====== /* Systemtap tapset to make it easier to trace Python */ /* Define python.function.entry/return: */ probe python.function.entry = process("python").library("/usr/lib64/libpython3.9.so.1.0").mark("function__entry") { filename = user_string($arg1); funcname = user_string($arg2); lineno = $arg3; } probe python.function.return = process("python").library("/usr/lib64/libpython3.9.so.1.0").mark("function__return") { filename = user_string($arg1); funcname = user_string($arg2); lineno = $arg3; } ====== 8< ====== It is analogy to /usr/lib64/libpython3.6m.so.1.0 packaged within python3-libs-3.6.8-18.el7.x86_64, or /usr/share/systemtap/tapset/libpython2.7-64.stp packaged within python2-libs-2.7.18-8.module+el8.6.0+12703+136ebe63.x86_64 > If not, since systemtap-client is already providing Python integration, > shouldn't it provide this file as well? The practical problem here is that systemtap doesn't know the library name to probe. At the python.rpm brew build time, you can use the rpm macros to reliably generate this tapset file. That can hardly be done on the systemtap side. Could you, please put this missing tapset file back to python3-libs.rpm? After some testing, included that file in the systemtap tree: https://sourceware.org/git/?p=systemtap.git;a=commit;h=39b5233271b997811632871e1b6620a89b384fe8 Thanks. I didn't know wildcards were possible, this way it looks better. And systemtap maintainers are probably better people to test this. One more thing: what's the "python"? If it's the name of the executable, it might be good to add `python3` and `python3.*`. (In reply to Petr Viktorin from comment #6) > One more thing: what's the "python"? If it's the name of the executable, it > might be good to add `python3` and `python3.*`. That's a symlink to python3 provided by python-unversioned-command.rpm. Without it, the tapset wouldn't work. Re-fixed: https://sourceware.org/git/?p=systemtap.git;a=commitdiff;h=3b2d9da3d014f6470c7eb9533f5e0249ca977e3e;hp=39b5233271b997811632871e1b6620a89b384fe8 Thanks! Verified, all arches. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: systemtap), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:2514 |