Description of problem: stap /usr/share/doc/python-libs-2.6.4/systemtap-example.stp fails Version-Release number of selected component (if applicable): python-libs-2.6.4-27.fc13.x86_64 python-libs-2.6.4-27.fc13.i686 systemtap-1.2-1.fc13.x86_64 python-debuginfo-2.6.4-27.fc13.x86_64 How reproducible: always Steps to Reproduce: 1. On a x86_64 F13 system, yum -y install python-libs.x86_64 python-libs.i686 systemtap 2. debuginfo-install python 3. stap /usr/share/doc/python-libs-2.6.4/systemtap-example.stp Actual results: WARNING: cannot find module /usr/lib/libpython2.6.so.1.0 debuginfo: No DWARF information found semantic error: no match while resolving probe point process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__entry") WARNING: cannot find module /usr/lib/libpython2.6.so.1.0 debuginfo: No DWARF information found semantic error: no match while resolving probe point process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__return") Pass 2: analysis failed. Try again with another '--vp 01' option. Expected results: Python function callgraph printout
I don't have a x86_64 install around, but this looks like an issue with the python-libs.i686 variant. Does it work if you remove the i686 version or if you install the i686 debuginfo package for libpython?
1. It works if I remove python-libs.i686 2. If I remove python-debuginfo.x86_64 and install python-debuginfo.i686 and python-libs.i686, stap fails: stap /usr/share/doc/python-libs-2.6.4/systemtap-example.stp WARNING: cannot find module /usr/lib/libpython2.6.so.1.0 debuginfo: No DWARF information found semantic error: no match while resolving probe point process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__entry") WARNING: cannot find module /usr/lib64/libpython2.6.so.1.0 debuginfo: No DWARF information found semantic error: no match while resolving probe point process("python").library("/usr/lib64/libpython2.6.so.1.0").mark("function__entry") semantic error: no match while resolving probe point python.function.entry WARNING: cannot find module /usr/lib/libpython2.6.so.1.0 debuginfo: No DWARF information found semantic error: no match while resolving probe point process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__return") WARNING: cannot find module /usr/lib64/libpython2.6.so.1.0 debuginfo: No DWARF information found semantic error: no match while resolving probe point process("python").library("/usr/lib64/libpython2.6.so.1.0").mark("function__return") semantic error: no match while resolving probe point python.function.return Pass 2: analysis failed. Try again with another '--vp 01' option. Missing separate debuginfos, use: debuginfo-install python-libs-2.6.4-27.fc13.i686 python-libs-2.6.4-27.fc13.x86_64 NOTE: 1. I intentionally installed python-libs.i686 in order to run some i686 application on my x86_64 machine. 2. I understand that the i686 and x86_64 debuginfo packages cannot coexist and that many people find 'multilib' to be a pain but I suggest make probing python-libs.x86_64 while python-libs.i686 is installed work by default and give a better error message when trying to probe python-libs.i686 on an x86_64
Thanks for testing. So the issue is that python-libs.i686 installs /usr/share/systemtap/tapset/libpython2.6-32.stp and python-libs.x86_64 installs /usr/share/systemtap/tapset/libpython2.6-64.stp. Both define a probe python.function.entry. The first as: probe python.function.entry = process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__entry") The second as: probe python.function.entry = process("python").library("/usr/lib64/libpython2.6.so.1.0").mark("function__entry") So if you have both installed it needs to resolve both variants. Which means you have to install both the 32 and 64 version of the debuginfo package. I see in comment #3 that is actually what stap recommends. Doesn't it recommend the same for the example from comment #1 ? It seems a bit strange that the debuginfo packages conflict. But maybe that is by design. If so we need to find a way to make either of the probe alias definitions optional. You can do this by hand for now to test if it works by adding a ? after one or both. e.g.: probe python.function.entry = process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__entry") ? { ... } But that isn't a full solution since if you do that for both then nothing will match if you don't have any debuginfo package installed. Anybody have a better/smarter idea how to resolve this?
(In reply to comment #3) > Doesn't it recommend the same for the example from comment #1 ? When I have python-libs.{i686,x86_64} and python-debuginfo.x86_64 installed, stap does not recommend running debuginfo-install > You can do this by hand for now to test if it works by adding a ? after one or both. Adding a '?" to only the arch with debuginfo installed indeed works. As a user of the development tools shipped on Fedora, I would like to install both i686 and x86_64 debuginfo for ex: python on my system. I understand that the developers who did the separate debuginfo work upstream and in Fedora also works on systemtap so hopefully this could be made to work in the long term.
> Adding a '?" to only the arch with debuginfo installed indeed works. Should be: adding '?' to the arch WITHOUT debuginfo installed.
Both debuginfos should in principle coexist. Is there an RPM-level conflict between them? Systemtap should find the right one based upon the probed process (file) name.
(In reply to comment #6) > Both debuginfos should in principle coexist. Is there an RPM-level conflict > between them? 1. rpm complains about file conflicts indeed: rpm -i python-debuginfo-2.6.4-25.fc13.i686.rpm python-debuginfo-2.6.4-25.fc13.x86_64.rpm file /usr/lib/debug/usr/bin/python.debug conflicts between attempted installs of python-debuginfo-2.6.4-25.fc13.i686 and python-debuginfo-2.6.4-25.fc13.x86_64 file /usr/lib/debug/usr/bin/python2.6.debug conflicts between attempted installs of python-debuginfo-2.6.4-25.fc13.i686 and python-debuginfo-2.6.4-25.fc13.x86_64 file /usr/src/debug/Python-2.6.4/Modules/getpath.c conflicts between attempted installs of python-debuginfo-2.6.4-25.fc13.i686 and python-debuginfo-2.6.4-25.fc13.x86_64 2. debuginfo-install python.i686 on a x86_64 box does nothing 3. If I install python-debuginfo.i686 then run "debuginfo-install python" debuginfo "upgrades" python-debuginfo.i686 to python-debuginfo.x86_64. i.e. removes the i686 debuginfo I thought the i686 and x86_64 archs conflict for all debuginfo packages?
Such conflicts are unfortunate, not unheard of, but not universal. Some fedora packaging policy changes would have to be adopted to nix them. One possibility is to break up debuginfo by binary rpm rather than source rpm, so that all of foo.32, foo.64, foo-libs.32, and foo-libs.64 would get their own debuginfo. Only the former pair would conflict. Another possibility is to teach RPM to drop/ignore the filename-based /usr/lib/debug/bin/foo.debug files, and leave only the build-id-based ones, which won't conflict across multilibs. Another possibility is for python to use the forthcoming debuginfo-less sys/sdt.h option that will appear in systemtap 1.3. It's not an exact substitute (possibly requiring @cast()'s on the passed $args), but should work around this problem. Another possibility is to manually plop debuginfo for python-libs.* under the ABRT lookaside cache, where filename-based conflicts appear to be tolerated; that's basically equivalent to the rpm change idea above. systemtap-1.3 will look under /var/cache/abrt-di/usr/lib/debug/.build-id
(See bug #604123 for an RFE on one of those options.)
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.