Bug 564429

Summary: Errors parsing .probes section in the presence of prelink
Product: [Fedora] Fedora Reporter: Dave Malcolm <dmalcolm>
Component: systemtapAssignee: Mark Wielaard <mjw>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dsmith, fche, jistone, mjw, roland, wcohen
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 564445 (view as bug list) Environment:
Last Closed: 2010-02-19 09:21:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 563528    
Bug Blocks: 546295    
Attachments:
Description Flags
Log from invocation of systemtap none

Description Dave Malcolm 2010-02-12 17:45:12 UTC
Description of problem:
As discussed on IRC today, systemtap can sometimes fail to parse static markers in a library due to prelink.

Apparently this is fixed in git; I'm filing this bug and adding it to the F13 tracker bug to ensure that this fix makes it into F13.


Version-Release number of selected component (if applicable):
systemtap-1.1-1.fc13.i686

How reproducible:
Sometimes

Steps to Reproduce:
1. Prelink a library containing static markers:
  # prelink /usr/lib/libpython2.6.so.1.0
2. Try to use those markers:
  # stap -vvvvv --vp 01 /usr/share/doc/python-libs-2.6.4/systemtap-example.stp

 
Actual results:
semantic error: no match while resolving probe point process("python").library("/usr/lib/libpython2.6.so.1.0").mark("function__entry")
semantic error: no match while resolving probe point python.function.entry


Expected results:
Probepoint should work

Additional info:
Undoing prelink makes it work again:

# prelink -u /usr/lib/libpython2.6.so.1.0
# stap /usr/share/doc/python-libs-2.6.4/systemtap-example.stp -c yum help
     0 yum(25931): => <module> in /usr/lib/python2.6/site.py:59
   444 yum(25931):  => <module> in /usr/lib/python2.6/os.py:22
  1043 yum(25931):   => <module> in /usr/lib/python2.6/posixpath.py:11
  1155 yum(25931):    => <module> in /usr/lib/python2.6/stat.py:4
  1172 yum(25931):    <= <module> in /usr/lib/python2.6/stat.py:94
  1279 yum(25931):    => <module> in /usr/lib/python2.6/genericpath.py:5
  1298 yum(25931):    <= <module> in /usr/lib/python2.6/genericpath.py:85
  1492 yum(25931):    => <module> in /usr/lib/python2.6/warnings.py:1
  1688 yum(25931):     => <module> in /usr/lib/python2.6/linecache.py:6
  1707 yum(25931):     <= <module> in /usr/lib/python2.6/linecache.py:68
(snip)

I'm about to attach the more detailed error log from the failure.

Comment 1 Dave Malcolm 2010-02-12 17:46:14 UTC
Created attachment 390545 [details]
Log from invocation of systemtap

Comment 2 Dave Malcolm 2010-02-12 17:47:01 UTC
# eu-readelf -x .probes /usr/lib/libpython2.6.so.1.0 

Hex dump of section [24] '.probes', 84 bytes at offset 0x186940:
  0x00000000 66756e63 74696f6e 5f5f656e 74727900 function__entry.
  0x00000010 50524231 00000000 40691800 00000000 PRB1....@i......
  0x00000020 660a0c00 00000000 66756e63 74696f6e f.......function
  0x00000030 5f5f7265 7475726e 00000000 50524231 __return....PRB1
  0x00000040 68691800 00000000 6e100c00 00000000 hi......n.......
  0x00000050 00000000

Comment 3 Mark Wielaard 2010-02-12 18:55:56 UTC
This is upsteam bug "Markers get a bad address in prelinked libraries"
http://sourceware.org/bugzilla/show_bug.cgi?id=11173
Fix is already in upstream git, but just missed the 1.1 release

If we don't make a new systemtap release then in addition of the above patch we will also need commit 87748e.

commit 08d1d520616557f6ff7dd023e260ad6577e9e0e8
Author: Mark Wielaard <mjw>
Date:   Mon Jan 18 09:13:30 2010 +0100

    PR11173 Markers get a bad address in prelinked libraries.
    
    Our literal_addr_to_sym_addr() function was just wrong. To compensate for
    raw addresses read from elf (either given by the user or through a mark
    transformation) we need to know what the elf_bias is (as returned by
    dwfl_module_getelf) before feeding them to any libdwfl functions.
    
    * tapsets.cxx (query_module_dwarf): Always add elf_bias to raw function or
      statement addresses before calling query_addr().
      (query_addr): Don't call literal_addr_to_sym_addr().
    * dwflpp.h (literal_addr_to_sym_addr): Removed.
    * dwflpp.cxx (literal_addr_to_sym_addr): Likewise.

commit 87748e2b87e574d3c83866ccd0d83678c3c68d93
Author: Mark Wielaard <mjw>
Date:   Tue Feb 2 13:47:19 2010 +0100

    Make sure cfa_ops are always retrieved through dwfl global address.
    
    dwflpp::translate_location() works on the dw address space, but
    get_cfa_ops() starts out with dwfl calls (only dwarf_cfi_addrframe()
    needs to be adjusted for bias).
    
    * dwflpp.cxx (translate_location): Pass pc plus module bias through to
      get_cfa_ops.
      (get_cfa_ops): Adjust for bias when calling dwarf_cfi_addrframe(),
      add frame start/end address when found if verbose logging.
    * testsuite/systemtap.exelib/lib.stp: Add $foo and $bar variables to
      process.function probes.
    * testsuite/systemtap.exelib/libmarkunamestack.stp: Likewise.
    * testsuite/systemtap.exelib/lib.tcl: Expect correct values for
      process.function probe variables.
    * testsuite/systemtap.exelib/libmarkunamestack.tcl: Likewise.

That last patch relies on an elfutils fix: https://bugzilla.redhat.com/show_bug.cgi?id=546295

Comment 4 Mark Wielaard 2010-02-19 09:21:00 UTC
systemtap-1.1-2.fc13 and systemtap-1.1-2.fc12 have been pushed with the patches
from comment #3. Which should fix this issue mostly. Full fix will be when new
elfutils 0.145 lands (any day now).