Re: uprobes and empty functions

[Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>]

On Wed, 2010-11-03 at 14:29 -0700, Josh Stone wrote:
> On 11/02/2010 02:02 PM, Jim Keniston wrote:
> > Thanks.  The only problem I see is that if setup_uprobe_post_ssout()
> > rejects the instruction, you need to report that via printk().
> 
> OK, I added a printk report, ported it to uprobes "1", and pushed it out
> as commit 33d60a8.  Let's hope I didn't break the world...
> 
> In testing it, I did find a problem still, but it seemed to be broken
> before my changes too.  On i386, I get a SEGV while singlestepping on a
> relative call, e8.  x86_64 works fine on such calls.  For example, a
> snippet from stap's main():
> 
>  805292c: e8 2f cb 00 00    call   805f460 <_ZN17systemtap_sessionC1Ev>
>  8052931: 89 5c 24 08       mov    %ebx,0x8(%esp)
> 
> $ stap -e 'probe process("stap").statement(0x805292c) { println(pp()) }'
> -c 'stap -V' -gw
> process("/usr/local/bin/stap").statement(0x805292c)
> $ dmesg | tail -n2
> stap_bf9546c3238d167e5f1c89b1a484391c_1030: systemtap: 1.4/0.148, base:
> e2077000, memory: 25data/17text/1ctx/13net/8alloc kb, probes: 1
> Task died at uprobe probepoint:  pid/tgid = 3003/3003, probepoint =
> 0x805292c
> 
> vs.
> 
> $ stap -e 'probe process("stap").statement(0x8052931) { println(pp()) }'
> -c 'stap -V' -gw
> SystemTap translator/driver (version 1.4/0.148 commit
> release-1.3-209-ga44a7cb)
> Copyright (C) 2005-2010 Red Hat, Inc. and others
> This is free software; see the source for copying conditions.
> enabled features: AVAHI LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR
> TR1_UNORDERED_MAP
> process("/usr/local/bin/stap").statement(0x8052931)
> 
> 
> In both cases, our probe handler is running ok, but on the "call" the
> app is segfaulting.  I found that uprobe_pre_ssout looks ok, but then
> the next utrace callback we get is for a SIGSEGV (rather than our
> singlestep SIGTRAP).  So all the post_ssout changes I made aren't even
> in play here.
> 
> This happens on both 32-bit Fedora 13 and RHEL5, so uprobes1 and
> uprobes2 are both affected.
> 
> The only other thing I could find is that this only seems to happen on
> e8 calls with a positive displacement.  When negative, it seems ok, like on:
> 
>  80529b0: e8 8b cd ff ff    call   804f740
> <_ZL15remove_temp_dirR17systemtap_session>
> 
> Any idea?
> 
> 
> Josh

I wonder if this is the same problem reported in bugzilla #11249 (which
never got resolved, as far as I can tell).  In comment #5 there, I
speculated as follows:

The general protection fault on the call suggests that the destination
address
of the call is bad.  (I think the IP is left at the faulting instruction.)  The
destination is computed by adding the displacement in the call instruction to
the address of the next instruction.  If you're in a big vma (e.g.,
libc-x.x.so), that displacement can be big.  If you move the call instruction to
the (1-page) SSOL area, that big displacement can take you out of the SSOL vma,
to a potentially unmapped address.  Does that warrant a GP fault?  Uprobes
adjusts the IP after the call, so it's back in the probed vma, but by then it
may be too late.

Sorry, that's my only idea.  It looks interesting, but uprobes and stap
are no longer in my bailiwick.

Jim