Bug #3597
open
dtrace probe lookup ignores provider, asserts on conflict
0%
Description
Reproduce:
Download the example code. Compile using ./dtest.sh
In one window: ./dtest
In another: dtrace 64 -L . -Z -n 'ilc*:::*-probe {printf("Hello.");}'>pv_desc.dtvd_name, pdp->dtpd_provider) == 0, file ../common/dt_provider.c, line 246
Result:
Assertion failed: strcmp(pvp
If you run: dtrace -64 -Z -n 'ilc*:::*-probe {printf("Hello.");}'
The example acts as expected.
If the dtest program is not running before hand, the dtest program + dtrace work as expected.
Thanks,
Files
Updated by Joshua M. Clulow over 8 years ago
- Project changed from site to illumos gate
- Assignee set to Robert Mustacchi
Updated by Rich Lowe over 8 years ago
The assert trips because the provider name we get back is "ilc" unadorned, but the provider name associated with the probe is "ilc8675" (or whatever pid).
We appear to create the naked 'ilc' provider because of -L finding the source test.d in the current directory.
Seems a bit weird, to my uninformed self that -L will create providers but perhaps understandable.
Updated by Rich Lowe over 8 years ago
We're crashing when parsing the script actually. And actually, provider name is immaterial, dtrace_xstr2desc isn't filling that structure element, so any provider name is sufficient to trip us, as long as the probe name (naked) matches a pre-existing USDT probe.
Updated by Rich Lowe over 8 years ago
- Assignee changed from Robert Mustacchi to Rich Lowe
Updated by Rich Lowe over 8 years ago
- Subject changed from dtrace assertion error on USDT. to dtrace probe lookup ignores provider, asserts on conflict
What's going on is when we ask the kernel for probes in dt_probe_lookup, the provider isn't part of the pattern we hand down, so any conflicting probe name will cause us to trip the "same provider" assertion in dt_probe_discover (we're asserting, because otherwise we'll add them to the wrong provider).
I have a prototypical fix which forces dt_probe_lookup to root the probes to the specified provider, which works but might be wrong.
It's possible that, instead, the parser should actually hand us rooted probe names, when it's parsing provider specifications (it currently gives back "::name"). Though that'd involve dt_node_provider amending all the probe nodes, and seems more than a tad unclean itself.