Re: [PATCH v2 3/4] probe: do not try to reify probes from uncooked providers

[Nick Alcock <nick.alcock@oracle.com>]

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)