From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23176 invoked by alias); 17 Nov 2010 00:20:04 -0000 Received: (qmail 23120 invoked by uid 22791); 17 Nov 2010 00:20:02 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_BF,TW_XB X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Nov 2010 00:19:59 +0000 From: "jistone at redhat dot com" To: systemtap@sources.redhat.com Subject: [Bug uprobes/11249] uprobes fails on glibc get-pc-thunk call insn probe X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: uprobes X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jistone at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sources dot redhat.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 17 Nov 2010 00:20:00 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2010-q4/txt/msg00229.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11249 --- Comment #11 from Josh Stone 2010-11-17 00:19:44 UTC --- Belated update... later in that thread, I theorized that the GPF may be the CPU's check that the call target is within the segment boundaries. Roland helped me dig into this, and after "sysctl -w kernel.print-fatal-signals=1", I got: > [ 259.933657] #GPF(0[seg:0]) at bfb19020, CPU#0. > [ 259.934104] exec_limit: bfb1a000, user_cs: 0000fb19/00cbfb00. > [ 259.934707] stap/1684: potentially unexpected fatal signal 11. > [ 259.934709] code at bfb19020: e8 05 ea 00 00 8d 85 a8 fa ff ff 89 5c 24 08 89 > [ 259.934768] Pid: 1684, comm: stap Not tainted 2.6.35.6-45.fc14.i686 #1 /Bochs > [ 259.934771] EIP: 0073:[] EFLAGS: 00010346 CPU: 0 > [ 259.934779] EIP is at 0xbfb19020 > [ 259.934781] EAX: 00000000 EBX: bfb169f4 ECX: bfb16950 EDX: bfb163e0 > [ 259.934783] ESI: 00000002 EDI: 00000000 EBP: bfb16938 ESP: bfb16140 > [ 259.934785] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b > [ 259.934788] Process stap (pid: 1684, ti=dce12000 task=ddcf9940 task.ti=dce12000) > [ 259.935379] > [ 259.935381] Call Trace: > [ 259.937563] Task died at uprobe probepoint: pid/tgid = 1684/1684, probepoint = 0x80538f6 Notice in particular the exec_limit at bfb1a000. Our instruction at bfb19020 is 5 bytes, "e8 05 ea 00 00 : call +0xea05", which puts the call target at 0xbfb27a2a. So indeed, we appear to be leaving the segment. That's before uprobes corrects the IP, of course, but the CPU doesn't give us that chance. This is on a non-PAE kernel. Roland informed me that i686.PAE and x86_64 kernels don't put any bounds on the code segment, so I tried on a PAE kernel and could not reproduce the issue. (And we already knew x86_64 was ok). (In reply to comment #4) > I was using 2.6.29.4-167.fc11.i686.PAE in my analysis. > > Whats interesting is if we run a 2.6.33-rc4 git kernel from branch > utrace-gdbstub-uprobes from location git://web.elastic.org/~fche/utrace-ext.git > on the same machine, the problem disappears. Srikar's PAE result casts this into doubt, unless in F11 times the PAE kernel still kept segment limits. Or he misreported. ;) But I tried on F12-14 and RHEL5, and consistently the non-PAE would fail while the PAE worked fine. RHEL6 is always PAE, and also works fine. So - if we care about non-PAE kernels, we'll need to either refuse to probes these relative instructions, or figure out a pre_ssout correction to keep the target in bounds. But at least on i686.PAE and x86_64, it seems ok. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.