Bug 604013 - python-libs-2.6.4/systemtap-example.stp fails
python-libs-2.6.4/systemtap-example.stp fails
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Malcolm
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-15 03:29 EDT by Scott Tsai
Modified: 2011-06-27 14:15 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 14:15:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Tsai 2010-06-15 03:29:02 EDT
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
Comment 1 Mark Wielaard 2010-06-15 03:54:56 EDT
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?
Comment 2 Scott Tsai 2010-06-15 04:46:16 EDT
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
Comment 3 Mark Wielaard 2010-06-15 05:39:48 EDT
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?
Comment 4 Scott Tsai 2010-06-15 06:43:07 EDT
(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.
Comment 5 Scott Tsai 2010-06-15 06:44:41 EDT
> Adding a '?" to only the arch with debuginfo installed indeed works.

Should be: adding '?' to the arch WITHOUT debuginfo installed.
Comment 6 Frank Ch. Eigler 2010-06-15 07:38:41 EDT
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.
Comment 7 Scott Tsai 2010-06-15 08:11:52 EDT
(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?
Comment 8 Frank Ch. Eigler 2010-06-15 09:08:49 EDT
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
Comment 9 Frank Ch. Eigler 2010-06-15 09:23:42 EDT
(See bug #604123 for an RFE on one of those options.)
Comment 10 Bug Zapper 2011-06-02 06:49:11 EDT
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
Comment 11 Bug Zapper 2011-06-27 14:15:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.