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

[Randy MacLeod]

On 5/14/19 10:08 AM, Richard Purdie wrote:
> On Mon, 2019-05-13 at 23:57 -0400, Randy MacLeod wrote:
>> About half the ptests will fail if the executables deployed
>> as part of the ptest package are stripped. Currently
>> there is no easy way to only strip the main valgrind
>> package so leave it and the ptests *all* unstripped.
>>
>> There is an enhancement filed to enable wildcard stripping:
>>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=13343
>> so this recipe can be fixed once that is implemented.
>>
>> Signed-off-by: Randy MacLeod <Randy.MacLeod at windriver.com>
>> ---
>>   meta/recipes-devtools/valgrind/valgrind_3.15.0.bb | 4 ++++
>>   1 file changed, 4 insertions(+)
> 
> I did test whether we could get away with a dependency on valgrind-dbg
> as in theory that should behave the same way. It doesn't which means
> the debug symbol linkage isn't being honoured by valgrind and that is
> something we need to look into too :/.

I tried that as well. When it didn't work and I couldn't find an
example that used that sort of dependency, I looked for other solutions
and ended up with the admittedly poor one here which only has the
one benefit that it works. ;-)

Ross asked about the disk usage impact:

du -sk for .../packages-split/foo

Type         valgrind    valgrind-ptest
unstripped   169732      138192
stripped      27224       99836

ls -l /.../packages-split/usr/bin/valgrind
unstripped: 88672
   stripped: 22728

To be sure such bloat doesn't slip into the 2.8 release,
we should probably wait for the partial stripping ER implementation
and/or I can figure out what's wrong with adding a
    valgrind-ptest -> valgrind-dbg
dependency.

> 
> I'm torn on whether to accept this patch or try and fix partial
> stripping...

Let's wait. See above.

We at least understand all but one of the valgrind ptest problems
that were happening on x86-64. The drd/tests/pth_detached3 [1] failure
seems to be with valgrind itself. The executable is meant to segfault
and it does:

root at qemux86-64:/usr/lib/valgrind/ptest# drd/tests/pth_detached3
[ 2148.508705] pth_detached3[9127]: segfault at 7ffc5acd0090 ip 
0000003a0460a15c sp 00007ffc5accfa08 error 6 in 
libpthread-2.29.so[3a04607000+f000]
[ 2148.515650] Code: 10 00 00 00 f0 83 88 08 03 00 00 10 64 48 8b 3c 25 
00 03 00 00 e8 64 7c 00 00 0f 1f 40 00 8b 87 d0 02 00 00 85 c0 78 36 31 
c0 <f6
Segmentation fault

but when run under valgrind, there's an extra frame in the stack trace:

root at qemux86-64:# cat drd/tests/pth_detached3.stderr.diff1
--- pth_detached3.stderr.exp1   2019-05-14 15:46:06.000000000 +0000
+++ pth_detached3.stderr.out    2019-05-14 16:13:34.355000000 +0000
@@ -1,12 +1,19 @@

  pthread_detach(): invalid thread ID 0x........
-   at 0x........: pthread_detach (drd_pthread_intercepts.c:?)
+   at 0x........: vgDrd_set_joinable (drd_pthread_intercepts.c:?)
+   by 0x........: pthread_detach (drd_pthread_intercepts.c:?)
     by 0x........: main (pth_detached3.c:21)
...

I need to learn a bit more before considering whether to just add
the missing lines to the expected output file to allow the test to pass.

qemuarm64 is still a problem that I intend to work on it soon.
ptests trigger the OOM killer even if I give the system 3GB of RAM
but I haven't really worked to understand why.

../Randy

> 
> Cheers,
> 
> Richard
> 


-- 
# Randy MacLeod
# Wind River Linux


[1] drd/tests/pth_detached3.c

/* Invoke pthread_detach() with an invalid thread ID. */

#include <assert.h>
#include <errno.h>
#include <pthread.h>
#include <stdio.h>

static void* thread_func(void* arg)
{
   return 0;
}

int main(int argc, char** argv)
{
   pthread_t thread;

   pthread_create(&thread, NULL, thread_func, NULL);
   pthread_join(thread, NULL);

   /* Invoke pthread_detach() with the thread ID of a joined thread. */
   pthread_detach(thread);

   /* Invoke pthread_detach() with an invalid thread ID. */
   pthread_detach(thread + 8);

   fprintf(stderr, "Finished.\n");

   return 0;
}