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.macl...@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@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@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;
}
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
