[DTrace-devel] test FAILs with "5d3365d7 First implementation of the printf action"

[Kris Van Hees]

On Tue, Jul 14, 2020 at 08:42:57PM -0400, Kris Van Hees wrote:
> On Tue, Jul 14, 2020 at 04:21:13PM -0700, Eugene Loh wrote:
> > Starting with the above patch, I get consistent FAILs with
> > 
> >          test/unittest/actions/printf/tst.conv_a.d
> >          test/unittest/builtinvar/tst.hpriority.d
> >          test/unittest/builtinvar/tst.lwpsinfo1.d
> >          test/unittest/inline/tst.InlineTypedef.d
> >          test/unittest/lexer/tst.keyword-member.d
> >          test/unittest/printf/tst.str.d
> > 
> > The first one does a "printf("%a", &`max_pfn)" and prints 
> > "vmlinux`max_pfn" (which one would expect from the documentation or 
> > DTv1) but the .r file expects "{ptr}".  How could this test ever have 
> > PASSed?
> 
> That was a mistake, and thank you for catching it.  I fixed the .r file but
> in the process of making other chagnes, I accidentally dropped that change
> and didn't notice it.

I was looking at something remotely related and found out what happened.  I
actually didn't make a mistake (per se) - I reversed that change in my tree
because it was not resolving the address back to a symbol name on my Debian
dev VM.  I assume it must be something broken in the kallsyms handling.

I'll fix the actual bug in kallsyms and fix this test as well, because it
definitely should beable to map the address back to the symbol name.
> 
> > The remaining five FAIL because BPF complains of an invalid memory 
> > access, presumably because we're asking BPF to dereference pointers it 
> > does not recognize.  I assume we do not yet support access to kernel 
> > variables like that, and the tests used to PASS since they didn't do 
> > anything and didn't check anything but now they are trying to do something.
> 
> Correct.
> 
> > What I'm trying to figure out is if this patch was put back with FAILing 
> > tests (and a new test that was broken).  I don't understand.
> 
> The tests that fail (other than the incorrect .r file for the first one) do
> not fail because of this patch but because other functionality (performing
> loads from kernel memory locations) does not work yet.  Marking them in this
> patch as XFAIL would be wrong because the failure is not because of the
> patch.
> 
> I should have already submitted a patch to mark these as XFAIL due to the
> memory access issue but (1) I was hoping to solve that problem by now (which
> I was not able to do due to other tasks), and (2) I usually defer the marking
> of tests (unless part of a specific other patch) until closer to a release so
> that I can group them together (where that makes sense).
> 
> So yes, the first test will be fixed (thanks again) and the other tests will be
> marked XFAIL before we set the next errata release tag.
> 
> _______________________________________________
> DTrace-devel mailing list
> DTrace-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/dtrace-devel