This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug runtime/14348] Systemtap systemtap.base/buildid.exp hangs on F17 machines


http://sourceware.org/bugzilla/show_bug.cgi?id=14348

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #9 from David Smith <dsmith at redhat dot com> 2012-07-26 16:22:19 UTC ---
Here's some more info on this bug.

The buildid2.exp testcase modifies the buildid.x executable.  Here's the
original executable:

===
# eu-readelf -n ./buildid.x
Note section [ 2] '.note.ABI-tag' of 32 bytes at offset 0x21c:
  Owner          Data size  Type
  GNU                   16  VERSION
    OS: Linux, ABI: 2.6.32

Note section [ 3] '.note.gnu.build-id' of 36 bytes at offset 0x23c:
  Owner          Data size  Type
  GNU                   20  GNU_BUILD_ID
    Build ID: c62eb8e35b2b8729e42291c813235bc94a20ab68
===

After the testcase uses objcopy to modify it:

===
# eu-readelf -n ./buildid.x

Note section [ 2] '.note.ABI-tag' of 32 bytes at offset 0x21c:
  Owner          Data size  Type
  GNU                   16  VERSION
    OS: Linux, ABI: 2.6.32

Note section [ 3] '.note.gnu.build-id' of 73 bytes at offset 0x23c:
  Owner          Data size  Type
  GNU                   20  GNU_BUILD_ID
    Build ID: f9e1c2e8b7ddf2ee5b73eb58f03654be99c945c2
  GNU                   20  GNU_BUILD_ID
    Build ID: 57eec9e035f81d85c685c88f31d10f31f6768b8c
eu-readelf: cannot get content of note section: offset out of range
===

So, that's a bit scary - the fact that the offset is out of range and the fact
that the .note.gnu.build-id section has doubled in size.

When stap is run on the original executable, we get:

===
# stap -p2 ../../src/testsuite/systemtap.base/buildid.stp ./buildid.x
# functions
_dwarf_tvar_get_x_0:long ()
# probes
process("/es/scratch/dsmith/systemtap/f17-64/testsuite/1/buildid.x").function("foo@../../src/testsuite/systemtap.base/buildid.c:5")
/* pc=.absolute+0x547 */ /* <-
process("/es/scratch/dsmith/systemtap/f17-64/testsuite/1/buildid.x").function("foo@../../src/testsuite/systemtap.base/buildid.c:5").label("label")
=
process("/es/scratch/dsmith/systemtap/f17-64/testsuite/1/buildid.x").function("foo@../../src/testsuite/systemtap.base/buildid.c:5")
<- process("./buildid.x").function("foo").label("label") */
===

So, the probe is at 0x547.

When run on the modified executable, we get:

===
stap -p2 ../../src/testsuite/systemtap.base/buildid.stp ./buildid.x
# functions
_dwarf_tvar_get_x_0:long ()
# probes
process("/es/scratch/dsmith/systemtap/f17-64/testsuite/buildid.x").function("foo@../../src/testsuite/systemtap.base/buildid.c:5")
/* pc=.absolute+0x567 */ /* <-
process("/es/scratch/dsmith/systemtap/f17-64/testsuite/buildid.x").function("foo@../../src/testsuite/systemtap.base/buildid.c:5").label("label")
=
process("/es/scratch/dsmith/systemtap/f17-64/testsuite/buildid.x").function("foo@../../src/testsuite/systemtap.base/buildid.c:5")
<- process("./buildid.x").function("foo").label("label") */
===

On the new executable, the probe should be at 0x567, 0x20 bytes past the
original address.

The hang here might be related to how inode-uprobes work.  With the old
utrace-based uprobes, when we find the target process we check the buildid,
then install the probe(s).  With the new inode-based uprobes, we actually
install the probe(s) at module startup, then when we find the target process we
check the buildid (if I'm understanding the code correctly).

I'm wondering if the bad address we're installing the probe at is causing this
hang (possibly the bad probe location isn't on an instruction boundary for
instance).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]