[OE-core] [PATCH 2/5] valgrind: do not strip the package or ptests

[Randy MacLeod]

On 5/14/19 5:46 PM, richard.purdie at linuxfoundation.org wrote:
> On Tue, 2019-05-14 at 17:42 -0400, Randy MacLeod wrote:
>> On 5/14/19 5:32 PM, richard.purdie at linuxfoundation.org wrote:
>>> Actually, my test was flawed. I just retested and this time it
>>> worked.
>>> What I tested with was:
>>>
>>> RDEPENDS_${PN}-ptest += " sed perl perl-module-file-glob ${PN}
>>> ${PN}-dbg"
>>> INSANE_SKIP_${PN}-ptest = "debug-deps"
>>
>> Ah nice. Thanks.
> 
> Note I add PN above, I'm going to send a different patch which does
> that in the ptest bbclass as it fixes a ton of problems. Its not quite
> a straightforward patch though.
> 
>>> Can you see if that works for you?
>>
>> Sure. I'll test and resend the whole series.
>>
>>> We also have a problem that its overflowing the 4GB limit on some
>>> image
>>> sizes with the debug info included :/
>>
>> There's an enhancement to track that:
>>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=13025
>> Kevin owns it and has it scheduled for 2.8 M2.
> 
> The immediate problem will have to be fixed before valgrind can merge:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/602
> 
> Cheers,
> 
> Richard
> 

More test results!

The qemuarm64 valgrind ptest failures are due to a hard-coded
timeout patch in vg_regtest. It timed out at 30 seconds but
always left orphaned process hanging which eventually triggered
an OOM killer rampage. I bumped the timeout to 300 seconds to
see what that would do. It takes a long, long time but
the final result is the same as x86:

qemuarm64:
=== Test Summary ===
TOTAL: 159
PASSED: 149
FAILED: 1
SKIPPED: 9
DURATION: 10083
END: /usr/lib/valgrind/ptest
2019-05-14T23:16


qemuppc (300 second timeout):
=== Test Summary ===
TOTAL: 159
PASSED: 146
FAILED: 3
SKIPPED: 10
DURATION: 5492
END: /usr/lib/valgrind/ptest
2019-05-15T01:59
STOP: ptest-runner
root at qemuppc:/usr/lib/valgrind/ptest# grep FAIL 
valgrind_ptest_20190515-002816.log
FAIL: drd/tests/annotate_trace_memory
    but ^^^-- sorting exp-32bit and out file -> no diff
FAIL: drd/tests/annotate_trace_memory_xml <-- same
FAIL: drd/tests/std_list
FAILED: 3

I'm not sure why the output file is not ordered as expected but
I will likely not investigate qemuppc unless someone knows of a
use-case where this is an actual problem.


We need to agree on how to handle the ptest timeout.
I'll check if other recipes accept the optional timeout from:
    # ptest-runner -h
    Usage: ptest-runner [-d directory] [-e exclude] [-l list] \
      [-t timeout] [-x xml-filename] [-h] [ptest1 ptest2 ...]

It's tempting to just bump the timeout to 300 seconds
since anything that fails with that timeout really should
be fixed. The right thing is to pass the timeout from ptest-runner
down to valgrind's vg_regtest script. If we have people who set
timeouts to a non-default value and will be running valgrind's
ptest then I could do that.

Since I'm a completist, I'm going to try qemumips64 next! :)
-- 
# Randy MacLeod
# Wind River Linux