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.
Created attachment 390545 [details] Log from invocation of systemtap
# 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
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
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).