|
From: Anmol P. <An...@fr...> - 2014-10-20 23:36:11
|
Hello,
I see failures in my armv7 valgrind-3.10.0 run that I am guessing have to do with missing glibc debug packages and/or having a stripped glibc.
Just thought I'd run this past you folks just in case someone's seen this before:
root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# uname -a
Linux ls1021aqds 3.12.0+ #1 SMP Thu Oct 16 17:22:18 CDT 2014 armv7l GNU/Linux
root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# cat drd/tests/annotate_barrier.stderr.diff
--- annotate_barrier.stderr.exp 2014-10-17 16:11:30.557529158 +0000
+++ annotate_barrier.stderr.out 2014-10-20 22:25:27.965963442 +0000
@@ -24,8 +24,6 @@
Thread 2:
Conflicting store by thread 2 at 0x........ size 4
at 0x........: threadfunc (annotate_barrier.c:?)
- by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
- by 0x........: (within libpthread-?.?.so)
Address 0x........ is at offset 0 from 0x......... Allocation context:
at 0x........: malloc (vg_replace_malloc.c:...)
bys1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# .c:?)
root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# file /lib/libc-2.18-2013.10.so
/lib/libc-2.18-2013.10.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds#
If it is not the above, I'd next try to debug drd/drd_error.c around line 201:
print_err_detail("%sConflicting %s by thread %d at 0x%08lx size %ld%s\n",
what_prefix, dri->access_type == eStore ? "store" : "load",
dri->tid, dri->addr, dri->size, what_suffix);
VG_(pp_ExeContext)(VG_(get_error_where)(err)); // Fails?
Am I on the right track?
Thank you ,
Anmol.
|
|
From: Bart V. A. <bva...@ac...> - 2014-10-21 13:53:58
|
On 10/21/14 01:36, Anmol Paralkar wrote:
> I see failures in my armv7 valgrind-3.10.0 run that I am guessing have
> to do with missing glibc debug packages and/or having a stripped glibc.
>
> Just thought I’d run this past you folks just in case someone’s seen
> this before:
>
> root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# uname -a
>
> Linux ls1021aqds 3.12.0+ #1 SMP Thu Oct 16 17:22:18 CDT 2014 armv7l
> GNU/Linux
>
> root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# cat
> drd/tests/annotate_barrier.stderr.diff
>
> --- annotate_barrier.stderr.exp 2014-10-17 16:11:30.557529158 +0000
>
> +++ annotate_barrier.stderr.out 2014-10-20 22:25:27.965963442 +0000
>
> @@ -24,8 +24,6 @@
>
> Thread 2:
>
> Conflicting store by thread 2 at 0x........ size 4
>
> at 0x........: threadfunc (annotate_barrier.c:?)
>
> - by 0x........: vgDrd_thread_wrapper (drd_pthread_intercepts.c:?)
>
> - by 0x........: (within libpthread-?.?.so)
>
> Address 0x........ is at offset 0 from 0x......... Allocation context:
>
> at 0x........: malloc (vg_replace_malloc.c:...)
>
> bys1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# .c:?)
>
> root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds# file
> /lib/libc-2.18-2013.10.so
>
> /lib/libc-2.18-2013.10.so: ELF 32-bit LSB shared object, ARM, EABI5
> version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux
> 2.6.16, stripped
>
> root@ls1021aqds:/home/anmol/valgrind-trunk-ls1021aqds#
>
> If it is not the above, I’d next try to debug drd/drd_error.c around
> line 201:
>
> print_err_detail("%sConflicting %s by thread %d at 0x%08lx size
> %ld%s\n",
>
> what_prefix, dri->access_type == eStore ? "store" :
> "load",
>
> dri->tid, dri->addr, dri->size, what_suffix);
>
> VG_(pp_ExeContext)(VG_(get_error_where)(err)); // Fails?
>
> Am I on the right track?
Hello Ammol,
As you can see in the nightly build output produced on various servers
DRD in general and this test case in particular run reliably on x86 and
PPC systems. I'm not sure what makes it fail on ARM. But I think that
the Valgrind stack backtrace code might be a better place to start than
the DRD source code.
Bart.
|
|
From: Philippe W. <phi...@sk...> - 2014-10-24 05:06:22
|
On Tue, 2014-10-21 at 15:53 +0200, Bart Van Assche wrote: > Hello Ammol, > > As you can see in the nightly build output produced on various servers > DRD in general and this test case in particular run reliably on x86 and > PPC systems. I'm not sure what makes it fail on ARM. But I think that > the Valgrind stack backtrace code might be a better place to start than > the DRD source code. Note that to investigate this, you can also compare the backtrace produced by valgrind with the backtrace produced by gdb, using --vgdb--error=0 and use then gdb+vgdb. Philippe |
|
From: Anmol P. <An...@fr...> - 2014-10-24 16:07:14
|
-----Original Message----- From: Philippe Waroquiers [mailto:phi...@sk...] Sent: Friday, October 24, 2014 12:06 AM To: Bart Van Assche Cc: Paralkar Anmol-B07584; val...@li... Subject: Re: [Valgrind-developers] DRD test failures. On Tue, 2014-10-21 at 15:53 +0200, Bart Van Assche wrote: > Hello Ammol, > > As you can see in the nightly build output produced on various servers > DRD in general and this test case in particular run reliably on x86 > and PPC systems. I'm not sure what makes it fail on ARM. But I think > that the Valgrind stack backtrace code might be a better place to > start than the DRD source code. Note that to investigate this, you can also compare the backtrace produced by valgrind with the backtrace produced by gdb, using --vgdb--error=0 and use then gdb+vgdb. Philippe [] Hello Bart and Philippe, Thank you very much for the advice; I'll investigate thus. Regards, Anmol. |