[DTrace-devel] [PATCH v2 3/4] probe: do not try to reify probes from uncooked providers
Nick Alcock
nick.alcock at oracle.com
Fri Nov 15 20:57:07 UTC 2024
On 15 Nov 2024, Kris Van Hees outgrape:
> On Thu, Nov 14, 2024 at 10:01:07PM +0000, Nick Alcock wrote:
>> If there is a syntax error in the middle of a .d script processed
>> by -h, we will be left with a provider in question in an uncooked
>> state (where dt_provider_create() has been called on it with a NULL
>> provider by dt_node_provider(), but it has not had its provider
>> set yet by dt_cook_provider()).
>>
>> In this case, the attempt to pop the parser stack on error will
>> fail because probe iteration is attempting to reify probes out
>> of providers without making sure they're cooked first:
>>
>> at libdtrace/dt_probe.c:1006
>> argv=0x535830, fp=0x21e4630, s=0x0) at libdtrace/dt_cc.c:789
>> fp=0x21e4630, s=0x0) at libdtrace/dt_cc.c:1419
>> at libdtrace/dt_cc.c:1441
>>
>> The fix is simple: treat providers with no provimpl just like we do
>> providers with no provide() method in their provimpl: they cannot provide
>> probes, so don't try. (Test coming in a later commit in this series.)
>
> This entire commit message (and the one-liner subject) are actually not
> quite correct in terms of what the problem is. It has nothing to do with
> cooked vs uncooked providers or probes. The problem is simply that the
> dt_probe_iter() functions calls the provide() hook in provider prior to
> trying to match probe descriptions, and that cannot be done for a provider
> without implementation. That is all.
Yes, but I was trying to say *why* that might happen.
> This also needs a test.
It's got one -- the parser-error test I posted in this series died in
two different ways if either of these bugs were present.
> I'm posting an alternative patch (with my reviewed-by) with updated commit
> message and 2 tests (signed-off-by for both of us since you wrote the code).
OK! Looking...
--
NULL && (void)
More information about the DTrace-devel
mailing list