[DTrace-devel] [PATCH v3 10/21] usdt: test improvements

Nick Alcock nick.alcock at oracle.com
Thu Feb 15 22:01:21 UTC 2024


On 15 Feb 2024, Kris Van Hees stated:

> On Tue, Jan 16, 2024 at 09:13:06PM +0000, Nick Alcock via DTrace-devel wrote:
>> This soups up test/unittest/usdt/tst.manyprocs.sh to test dtprobed's
>> cleaning up the wreckage of dead processes, by having every other process
>> kill itself rather than dying peacefully (and sending a DTRACEHIOC_REMOVE).
>> When doing in-tree testing (something we can detect via $dtrace), we can
>> also check the DOF stash itself to see whether the wreckage has been cleaned
>> up. (This isn't practical when doing systemwide testing because we don't
>> know how much DOF the dtprobed might legitimately be hanging on to.)
>> 
>> tst.multitrace.sh gains the ability to test DOF reparsing on upgrade,
>> waiting until the first probe-containing process has started and then
>> intentionally overwriting some of the parsed DOF with junk (in lieu of
>> actually changing struct dof_parsed on the fly :) ) and forcing a reparse
>> via a kill -USR2 (in lieu of communicating the complete argument list of
>> dtprobed down to this test just so it can be killed and restarted).
>> 
>> tst.multitrace.sh is no longer XFAIL: it is meant to pass now, and sometimes
>> it does. (It still fails a lot of the time, but this seems to be unrelated
>> bugs, not a general problem with doing multiple USDT traces at the same
>> time.)
>
> OK, but if this patch is failing a lot of the time rather than PASSing, it is
> not really much use (or that what it is meant to test is broken).  Why is the
> test so unstable?  What are the conditions under which it fails?  What are the
> bugs causing it to fail?

Good question. It's intermittent and rare enough that every time I've
tried to track it down, the bugs have vanished :/ I suspect I might have
fixed them already, so maybe I should just remove that paragraph!

-- 
NULL && (void)



More information about the DTrace-devel mailing list