This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug tapsets/18143] target_set tapset does not track threads created with clone()
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 20 Mar 2015 17:02:57 +0000
- Subject: [Bug tapsets/18143] target_set tapset does not track threads created with clone()
- Auto-submitted: auto-generated
- References: <bug-18143-6586 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=18143
--- Comment #7 from Josh Stone <jistone at redhat dot com> ---
(In reply to Max Timchenko from comment #4)
> Josh: looks like uprobe support is there: I'm running
> "Linux jessie 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)",
> $ grep UPRO /boot/config-3.16.0-4-amd64
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_UPROBES=y
> CONFIG_UPROBE_EVENT=y
Ok - it's not actually uprobes that matters in this exact case, but anyway your
later test shows it working.
> New theory: the probe process.begin is silently skipped when running in
> target thread mode (-x). This might be the reason the target_set tracking
> probe fails to run even though the patch is present and uprobe support is
> there, since I always point stap at a particular root process of interest.
Ugh, I think we need a new bug for this. I believe you're running into the
code that turns "process" into "process(PID)"/"process("FILE") for -x/-c. This
is helpful for things like "process.function" which actually need to parse
target information.
But in "process.begin" as used by target_set, we want to see all child
processes too, not just the initial target. AFAICT it is still doing that ok,
when I try a test with -x on something spawning children, but for some reason
it's validating the pid before it accepts the probe.
> testfile2.stp
> ---
> probe process.begin! {
> printf("Process begin, pid=%d\n", pid())
> }
>
> probe process.thread.begin! {
> printf("Thread begin, pid=%d\n", pid())
> }
>
> probe syscall.open {
> printf("Let's add one working probe")
> }
> ---
> $ stap -x 609 testfile2.stp
> Makefile:10: *** mixed implicit and normal rules: deprecated syntax
> Let's add one working probe
> Let's add one working probe
> ...
Strange that "!" lets these continue -- without those you'll still get the
"cannot probe pid" error. It's supposed to mark a probe sufficient, skipping
any alternates listed, but it appears to be working like the "?" optional
marker too. I don't think that's intended -- it's only "optional" as long as
something else in the chain resolves (or is marked truly "?" optional).
--
You are receiving this mail because:
You are the assignee for the bug.