[Bug tapsets/18143] target_set tapset does not track threads created with clone()

[jistone at redhat dot com]

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.