Sorry, -p doesn't seem useful when used in conjunction -l. I'm not sure if that's expected of not.
However, the -P blocks the -l command which looks like a wrong behavior:
dtrace -P demo7276 -l
Simple doesn't return
Note that dtrace -P 'demo*' -l works fine, as does dtrace -m demo -l: it's only non-wildcarded lookups by provider that block forever. Even -P 'demo7276*' works, i.e. a wildcard that expands only to this one thing. (I note that all the tests for this case in the DTrace testsuite we imported from Solaris are intended to be manually executed: I should automate them to ensure this never happens again.)
Looking into the cause now.
Diagnosed: we attempt to explicitly lock the dpr_lock() when creating pid and usdt probes, which is prohibited since it confuses the machinery by which we make a recursive lock out of a non-recursive one that we can use in condition variables. Thus we fail to realize the lock is already taken and soon end up double-locking a non-recursive mutex, and a hang ensues.
Fix trivial (already done, but coming up with some proper testcases for this too before releasing).
This wasn't that obvious for me ; despite the source code ;-).
Thank you for taking the feedback into account...
The testcases revealed another bug (not the same bug, though its symptoms are outwardly identical): dtrace -p $some_pid -P a-provider-without-wildcards hung.
That needs a rather more invasive fix, but it cleans up the code a good bit and fixes a bunch of other possible hangs at the same time. (And it's done, and waiting for the next release.)