Project

General

Profile

Bug #3597

dtrace probe lookup ignores provider, asserts on conflict

Added by Ira Cooper about 7 years ago. Updated about 7 years ago.

Status:
New
Priority:
Normal
Assignee:
Rich Lowe
Category:
-
Start date:
2013-02-28
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

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.");}'
Result:
Assertion failed: strcmp(pvp>pv_desc.dtvd_name, pdp->dtpd_provider) == 0, file ../common/dt_provider.c, line 246

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

dtest.tar.gz (441 Bytes) dtest.tar.gz Example code. Ira Cooper, 2013-02-28 04:08 PM

History

#1

Updated by Joshua M. Clulow about 7 years ago

  • Project changed from site to illumos gate
  • Assignee set to Robert Mustacchi
#2

Updated by Rich Lowe about 7 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.

#3

Updated by Rich Lowe about 7 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.

#4

Updated by Rich Lowe about 7 years ago

  • Assignee changed from Robert Mustacchi to Rich Lowe
#5

Updated by Rich Lowe about 7 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.

Also available in: Atom PDF