You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(5) |
2
(3) |
|
3
(2) |
4
(3) |
5
(16) |
6
(8) |
7
(6) |
8
(2) |
9
(4) |
|
10
(10) |
11
(22) |
12
(7) |
13
(10) |
14
(11) |
15
(8) |
16
(6) |
|
17
(11) |
18
|
19
(6) |
20
(8) |
21
(5) |
22
(11) |
23
(6) |
|
24
(1) |
25
(6) |
26
(4) |
27
(2) |
28
(1) |
29
|
30
(2) |
|
31
(5) |
|
|
|
|
|
|
|
From: <sv...@va...> - 2015-05-15 20:09:12
|
Author: carll
Date: Fri May 15 21:09:05 2015
New Revision: 15239
Log:
Patch 5 in a revised series of cleanup patches from Will Schmidt
Add a .exp for the pth_cond_destroy_busy for PPC64 big endian.
This is specifically to cover the last line of output as
seen on ppc64BE, which is "ERROR SUMMARY: X errors from 3 contexts",
where X is 6, versus 3 as seen on other architectures.
The additional errors show up on BE during the "Thread #1: pthread_cond
_destroy: destruction of condition variable being waited upon."
Signed-off-by: Will Schmidt <wil...@vn...>
This patch fixes Vagrind bugzilla 347686
Added:
trunk/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64
Modified:
trunk/helgrind/tests/Makefile.am
Modified: trunk/helgrind/tests/Makefile.am
==============================================================================
--- trunk/helgrind/tests/Makefile.am (original)
+++ trunk/helgrind/tests/Makefile.am Fri May 15 21:09:05 2015
@@ -46,6 +46,7 @@
pth_destroy_cond.vgtest \
pth_destroy_cond.stdout.exp pth_destroy_cond.stderr.exp \
pth_cond_destroy_busy.vgtest pth_cond_destroy_busy.stderr.exp \
+ pth_cond_destroy_busy.stderr.exp-ppc64 \
pth_spinlock.vgtest pth_spinlock.stdout.exp pth_spinlock.stderr.exp \
rwlock_race.vgtest rwlock_race.stdout.exp rwlock_race.stderr.exp \
rwlock_test.vgtest rwlock_test.stdout.exp rwlock_test.stderr.exp \
Added: trunk/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64
==============================================================================
--- trunk/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64 (added)
+++ trunk/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64 Fri May 15 21:09:05 2015
@@ -0,0 +1,50 @@
+
+---Thread-Announcement------------------------------------------
+
+Thread #x is the program's root thread
+
+---Thread-Announcement------------------------------------------
+
+Thread #x was created
+ ...
+ by 0x........: pthread_create@* (hg_intercepts.c:...)
+ by 0x........: main (pth_cond_destroy_busy.c:45)
+
+----------------------------------------------------------------
+
+Possible data race during read of size 1 at 0x........ by thread #x
+Locks held: none
+ at 0x........: my_memcmp (hg_intercepts.c:...)
+ by 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...)
+ by 0x........: main (pth_cond_destroy_busy.c:52)
+
+This conflicts with a previous write of size 4 by thread #x
+Locks held: none
+ ...
+ by 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
+ by 0x........: thread_func (pth_cond_destroy_busy.c:31)
+ by 0x........: mythread_wrapper (hg_intercepts.c:...)
+ ...
+ Address 0x........ is 4 bytes inside data symbol "s_cond"
+
+----------------------------------------------------------------
+
+Thread #x: pthread_cond_destroy: destruction of condition variable being waited upon
+ at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...)
+ by 0x........: main (pth_cond_destroy_busy.c:52)
+
+----------------------------------------------------------------
+
+Thread #x's call to pthread_cond_destroy failed
+ with error code 16 (EBUSY: Device or resource busy)
+ at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...)
+ by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...)
+ by 0x........: main (pth_cond_destroy_busy.c:52)
+
+First pthread_cond_destroy() call returned EBUSY.
+Second pthread_cond_destroy() call returned success.
+
+ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 0 from 0)
|
|
From: Matthias S. <zz...@ge...> - 2015-05-15 19:37:35
|
On 14.05.2015 22:28, Philippe Waroquiers wrote: > The patch below aims at allowing a backtrace when Valgrind does > client syscalls. I now tried two systems. * x86 gcc-4.8.4, gdb-7.9: Here I have for: (gdb) info symbol $eip vgModuleLocal_do_syscall_for_client_WRK + 60 in section .text (gdb) bt inline-frame.c:167: internal-error: inline_frame_this_id: Assertion `frame_id_p (*this_id)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n After patch: (gdb) bt #0 vgModuleLocal_do_syscall_for_client_WRK () at m_syswrap/syscall-x86-linux.S:122 #1 0x380b6fa6 in do_syscall_for_client (syscall_mask=0x2, tst=0xbed1bb28, syscallno=100) at m_syswrap/syswrap-main.c:313 #2 vgPlain_client_syscall (tid=496354177, trc=3968008192) at m_syswrap/syswrap-main.c:1682 #3 0xffffcd35 in ?? () After adding .cfi_offset statements: (gdb) bt #0 vgModuleLocal_do_syscall_for_client_WRK () at m_syswrap/syscall-x86-linux.S:124 #1 0x380b6fa6 in do_syscall_for_client (syscall_mask=0x2, tst=0xbee57b28, syscallno=162) at m_syswrap/syswrap-main.c:313 #2 vgPlain_client_syscall (tid=tid@entry=1, trc=trc@entry=77) at m_syswrap/syswrap-main.c:1682 #3 0x380b3220 in handle_syscall (tid=tid@entry=1, trc=77) at m_scheduler/scheduler.c:1103 #4 0x380b49b7 in vgPlain_scheduler (tid=tid@entry=1) at m_scheduler/scheduler.c:1416 #5 0x380c71b8 in thread_wrapper (tidW=1) at m_syswrap/syswrap-linux.c:103 #6 run_a_thread_NORETURN (tidW=1) at m_syswrap/syswrap-linux.c:156 #7 0x00000000 in ?? () The same is valid for calls into do_syscall_WRK (e.g. when adding --vgdb-stop-at=startup). * amd64 gcc-4.8.4 and gcc-4.9.2, gdb-7.9 For amd64 I have the same behaviour as you, a lot of strange entries inserted (for both gcc-4.8.4 and gcc-4.9.2). Checking x86 code in this system is the same as on the other system for gcc-4.8.4 (bad callstacks) x86 code with gcc-4.9.2, the callstacks look already good before. The updated patch is attached. Regards Matthias |
|
From: <sv...@va...> - 2015-05-15 16:50:14
|
Author: carll
Date: Fri May 15 17:50:06 2015
New Revision: 15238
Log:
Patch 6 in a revised series of cleanup patches from Will Schmidt
Fix multipleinheritance heuristic for ppc64LE (leak_cpp_interior test).
Adjust the PPC64 #ifdiffery to indicate that ppc64BE uses a thunk table,
but ppc64LE (in particular, the ELF ABIV2) does not. In this case, thunk
table == function descriptors.
Signed-off-by: Will Schmidt <wil...@vn...>
--
This patch replaces the previously posted "[6/7] add leak_cpp_interior
test .exp results ....."
This patch fixes Vagrind bugzilla 347686
Modified:
trunk/memcheck/mc_leakcheck.c
Modified: trunk/memcheck/mc_leakcheck.c
==============================================================================
--- trunk/memcheck/mc_leakcheck.c (original)
+++ trunk/memcheck/mc_leakcheck.c Fri May 15 17:50:06 2015
@@ -648,9 +648,9 @@
if (pot_fn == 0)
continue; // NULL fn pointer. Seems it can happen in vtable.
seg = VG_(am_find_nsegment) (pot_fn);
-#if defined(VGA_ppc64be) || defined(VGA_ppc64le)
- // ppc64 use a thunk table. So, we have one more level of indirection
- // to follow.
+#if defined(VGA_ppc64be)
+ // ppc64BE uses a thunk table (function descriptors), so we have one
+ // more level of indirection to follow.
if (seg == NULL
|| seg->kind != SkFileC
|| !seg->hasR
|
|
From: Carl E. L. <ce...@us...> - 2015-05-15 16:08:44
|
On Fri, 2015-05-15 at 10:09 -0500, Will Schmidt wrote:
> On Thu, 2015-05-14 at 15:07 -0700, Carl E. Love wrote:
> > On Mon, 2015-05-11 at 12:14 -0500, Will Schmidt wrote:
> > > Add a .exp for the tc06_two_races_xml for power.
> > > This is specifically to cover the last line of output as
> > > seen on ppc64BE, which is "ERROR SUMMARY: X errors from 3 contexts",
> > > where X is 6, versus 3 as seen on other architectures.
> > > The additional errors show up on BE during the "Thread #1: pthread_cond
> > > _destroy: destruction of condition variable being waited upon."
> > >
> > > Signed-off-by: Will Schmidt <wil...@vn...>
> > >
> > > --
> > >
> > > I did do some experimentation with filters for this change. Though I could
> > > squash the 3/6 values down to 0 to match, it would affect a number of other
> > > tests, and seemed rather invasive. I'm going with this as the most
> > > straightforward fix.
> > > ---
> > > helgrind/tests/Makefile.am | 1
> > > .../tests/pth_cond_destroy_busy.stderr.exp-ppc64 | 50 ++++++++++++++++++++
> >
> > Will:
> >
> > The first line of your message says "Add a .exp for the
> > tc06_two_races_xml.." but the expect file you are adding is for
> > "pth_cond_destroy_busy.stderr.exp-ppc64" I am guessing the first line
> > of your message was in error?
> >
> > Just want to make sure I am not missing something here.
>
> I must've messed that up when I was refreshing the patch descriptions.
> The body/contents are correct. If something still seems fishy I'll
> resubmit next time around.
>
Will:
I ran the test on Power 7, Power 8 (Big Endian) and Power 8 (Little
Endian) without the patch. I see the test fail on Power 8 BE only. Yet
when I look at the nightly regression tests I see the test also fails
for Power 7. So again, we have the case where the test fails on some
Power 7 systems but not others.
The only difference I see with the new expect file and the existing
expect file is:
< ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
---
> ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 0 from 0)
The new expect file reports 6 errors rather then 3 errors. Yet when I
look at the output from Valgrind, I can only count three errors. So, I
am confused as to why on some Power 7 platforms we report 6 errors?
I think we need to look into this test some more to understand why we
sometimes get "6 errors" instead of "3 errors" but only see three errors
mentioned in the report.
I am going to pass on this patch for the moment as well.
Carl Love
> Thanks,
> -Will
>
>
> >
> > Carl Love
> >
> >
> > > 2 files changed, 51 insertions(+)
> > > create mode 100644 helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64
> > >
> > > diff --git a/helgrind/tests/Makefile.am b/helgrind/tests/Makefile.am
> > > index e3dff80..c8409e1 100644
> > > --- a/helgrind/tests/Makefile.am
> > > +++ b/helgrind/tests/Makefile.am
> > > @@ -46,6 +46,7 @@ EXTRA_DIST = \
> > > pth_destroy_cond.vgtest \
> > > pth_destroy_cond.stdout.exp pth_destroy_cond.stderr.exp \
> > > pth_cond_destroy_busy.vgtest pth_cond_destroy_busy.stderr.exp \
> > > + pth_cond_destroy_busy.stderr.exp-ppc64 \
> > > pth_spinlock.vgtest pth_spinlock.stdout.exp pth_spinlock.stderr.exp \
> > > rwlock_race.vgtest rwlock_race.stdout.exp rwlock_race.stderr.exp \
> > > rwlock_test.vgtest rwlock_test.stdout.exp rwlock_test.stderr.exp \
> > > diff --git a/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64 b/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64
> > > new file mode 100644
> > > index 0000000..2da688e
> > > --- /dev/null
> > > +++ b/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64
> > > @@ -0,0 +1,50 @@
> > > +
> > > +---Thread-Announcement------------------------------------------
> > > +
> > > +Thread #x is the program's root thread
> > > +
> > > +---Thread-Announcement------------------------------------------
> > > +
> > > +Thread #x was created
> > > + ...
> > > + by 0x........: pthread_create@* (hg_intercepts.c:...)
> > > + by 0x........: main (pth_cond_destroy_busy.c:45)
> > > +
> > > +----------------------------------------------------------------
> > > +
> > > +Possible data race during read of size 1 at 0x........ by thread #x
> > > +Locks held: none
> > > + at 0x........: my_memcmp (hg_intercepts.c:...)
> > > + by 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...)
> > > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...)
> > > + by 0x........: main (pth_cond_destroy_busy.c:52)
> > > +
> > > +This conflicts with a previous write of size 4 by thread #x
> > > +Locks held: none
> > > + ...
> > > + by 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...)
> > > + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...)
> > > + by 0x........: thread_func (pth_cond_destroy_busy.c:31)
> > > + by 0x........: mythread_wrapper (hg_intercepts.c:...)
> > > + ...
> > > + Address 0x........ is 4 bytes inside data symbol "s_cond"
> > > +
> > > +----------------------------------------------------------------
> > > +
> > > +Thread #x: pthread_cond_destroy: destruction of condition variable being waited upon
> > > + at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...)
> > > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...)
> > > + by 0x........: main (pth_cond_destroy_busy.c:52)
> > > +
> > > +----------------------------------------------------------------
> > > +
> > > +Thread #x's call to pthread_cond_destroy failed
> > > + with error code 16 (EBUSY: Device or resource busy)
> > > + at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...)
> > > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...)
> > > + by 0x........: main (pth_cond_destroy_busy.c:52)
> > > +
> > > +First pthread_cond_destroy() call returned EBUSY.
> > > +Second pthread_cond_destroy() call returned success.
> > > +
> > > +ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 0 from 0)
> > >
> >
> >
>
>
|
|
From: Will S. <wil...@vn...> - 2015-05-15 15:09:15
|
On Thu, 2015-05-14 at 15:07 -0700, Carl E. Love wrote: > On Mon, 2015-05-11 at 12:14 -0500, Will Schmidt wrote: > > Add a .exp for the tc06_two_races_xml for power. > > This is specifically to cover the last line of output as > > seen on ppc64BE, which is "ERROR SUMMARY: X errors from 3 contexts", > > where X is 6, versus 3 as seen on other architectures. > > The additional errors show up on BE during the "Thread #1: pthread_cond > > _destroy: destruction of condition variable being waited upon." > > > > Signed-off-by: Will Schmidt <wil...@vn...> > > > > -- > > > > I did do some experimentation with filters for this change. Though I could > > squash the 3/6 values down to 0 to match, it would affect a number of other > > tests, and seemed rather invasive. I'm going with this as the most > > straightforward fix. > > --- > > helgrind/tests/Makefile.am | 1 > > .../tests/pth_cond_destroy_busy.stderr.exp-ppc64 | 50 ++++++++++++++++++++ > > Will: > > The first line of your message says "Add a .exp for the > tc06_two_races_xml.." but the expect file you are adding is for > "pth_cond_destroy_busy.stderr.exp-ppc64" I am guessing the first line > of your message was in error? > > Just want to make sure I am not missing something here. I must've messed that up when I was refreshing the patch descriptions. The body/contents are correct. If something still seems fishy I'll resubmit next time around. Thanks, -Will > > Carl Love > > > > 2 files changed, 51 insertions(+) > > create mode 100644 helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64 > > > > diff --git a/helgrind/tests/Makefile.am b/helgrind/tests/Makefile.am > > index e3dff80..c8409e1 100644 > > --- a/helgrind/tests/Makefile.am > > +++ b/helgrind/tests/Makefile.am > > @@ -46,6 +46,7 @@ EXTRA_DIST = \ > > pth_destroy_cond.vgtest \ > > pth_destroy_cond.stdout.exp pth_destroy_cond.stderr.exp \ > > pth_cond_destroy_busy.vgtest pth_cond_destroy_busy.stderr.exp \ > > + pth_cond_destroy_busy.stderr.exp-ppc64 \ > > pth_spinlock.vgtest pth_spinlock.stdout.exp pth_spinlock.stderr.exp \ > > rwlock_race.vgtest rwlock_race.stdout.exp rwlock_race.stderr.exp \ > > rwlock_test.vgtest rwlock_test.stdout.exp rwlock_test.stderr.exp \ > > diff --git a/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64 b/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64 > > new file mode 100644 > > index 0000000..2da688e > > --- /dev/null > > +++ b/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64 > > @@ -0,0 +1,50 @@ > > + > > +---Thread-Announcement------------------------------------------ > > + > > +Thread #x is the program's root thread > > + > > +---Thread-Announcement------------------------------------------ > > + > > +Thread #x was created > > + ... > > + by 0x........: pthread_create@* (hg_intercepts.c:...) > > + by 0x........: main (pth_cond_destroy_busy.c:45) > > + > > +---------------------------------------------------------------- > > + > > +Possible data race during read of size 1 at 0x........ by thread #x > > +Locks held: none > > + at 0x........: my_memcmp (hg_intercepts.c:...) > > + by 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...) > > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...) > > + by 0x........: main (pth_cond_destroy_busy.c:52) > > + > > +This conflicts with a previous write of size 4 by thread #x > > +Locks held: none > > + ... > > + by 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) > > + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) > > + by 0x........: thread_func (pth_cond_destroy_busy.c:31) > > + by 0x........: mythread_wrapper (hg_intercepts.c:...) > > + ... > > + Address 0x........ is 4 bytes inside data symbol "s_cond" > > + > > +---------------------------------------------------------------- > > + > > +Thread #x: pthread_cond_destroy: destruction of condition variable being waited upon > > + at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...) > > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...) > > + by 0x........: main (pth_cond_destroy_busy.c:52) > > + > > +---------------------------------------------------------------- > > + > > +Thread #x's call to pthread_cond_destroy failed > > + with error code 16 (EBUSY: Device or resource busy) > > + at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...) > > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...) > > + by 0x........: main (pth_cond_destroy_busy.c:52) > > + > > +First pthread_cond_destroy() call returned EBUSY. > > +Second pthread_cond_destroy() call returned success. > > + > > +ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 0 from 0) > > > > |
|
From: <sv...@va...> - 2015-05-15 13:17:24
|
Author: philippe
Date: Fri May 15 14:17:17 2015
New Revision: 15237
Log:
Add statistics about the nr of used linesF
Modified:
trunk/helgrind/libhb_core.c
Modified: trunk/helgrind/libhb_core.c
==============================================================================
--- trunk/helgrind/libhb_core.c (original)
+++ trunk/helgrind/libhb_core.c Fri May 15 14:17:17 2015
@@ -899,6 +899,34 @@
}
}
+/* Returns the nr of linesF which are in use. Note: this is scanning
+ the secmap wordFM. So, this is to be used for statistics only. */
+__attribute__((noinline))
+static UWord shmem__SecMap_used_linesF(void)
+{
+ UWord secmapW = 0;
+ Addr gaKey;
+ UWord inUse = 0;
+ UWord total = 0;
+
+ VG_(initIterFM)( map_shmem );
+ while (VG_(nextIterFM)( map_shmem, &gaKey, &secmapW )) {
+ UWord i;
+ SecMap* sm = (SecMap*)secmapW;
+ tl_assert(sm->magic == SecMap_MAGIC);
+
+ for (i = 0; i < sm->linesF_size; i++) {
+ LineF* lineF = &sm->linesF[i];
+ if (lineF->inUse)
+ inUse++;
+ total++;
+ }
+ }
+ VG_(doneIterFM)( map_shmem );
+ tl_assert (stats__secmap_linesF_allocd == total);
+
+ return inUse;
+}
/* ------------ LineF and LineZ related ------------ */
@@ -6334,9 +6362,10 @@
VG_(printf)(" linesZ: %'10lu allocd (%'12lu bytes occupied)\n",
stats__secmap_linesZ_allocd,
stats__secmap_linesZ_bytes);
- VG_(printf)(" linesF: %'10lu allocd (%'12lu bytes occupied)\n",
- stats__secmap_linesF_allocd,
- stats__secmap_linesF_bytes);
+ VG_(printf)(" linesF: %'10lu allocd (%'12lu bytes occupied)"
+ " (%'10lu used)\n",
+ stats__secmap_linesF_allocd, stats__secmap_linesF_bytes,
+ shmem__SecMap_used_linesF());
VG_(printf)(" secmaps: %'10lu in map (can be scanGCed %'5lu)"
" #%lu scanGC \n",
stats__secmaps_in_map_shmem,
|
|
From: <sv...@va...> - 2015-05-15 11:42:02
|
Author: philippe
Date: Fri May 15 12:41:54 2015
New Revision: 15236
Log:
This patch (re-)gains performance in helgrind, following revision 15207, that
reduced memory use doing SecMap GC, but was slowing down some workloads
(typically, workloads doing a lot of malloc/free).
A significant part of the slowdown came from the clear of the filter,
that was not optimised for big ranges : the filter was working byte
per byte till an 8 alignment. Then working per 8 bytes at a time.
With the patch, the filter clear is done the following way:
* all the bytes till 8 alignement are done together
* then 8 bytes at a time till filter_line alignment (32 bytes)
* then 32 bytes at a time.
Moreover, as the filter cache is small (1024 lines of 32 bytes),
clearing filter for ranges bigger than 32Kb was uselessly checking
several times the same entry. This is now avoided by using a range
check rather than a tag equality check.
As the new filter clear is significanly more complex than the previous simple
algorithm, the old algorithm is kept and used to check the new algorithm
when CHECK_ZSM is defined as 1.
The patch also contains a few micro optimisations and
disables
// VG_(track_die_mem_stack) ( evh__die_mem );
as this had no effect and was somewhat costly.
With this patch, we have almost reached for all perf tests the same
performance as we had before revision 15207. Some tests are still
slightly slower than before the SecMap GC (max 2% difference).
Some tests are now significantly faster (e.g. sarp).
For almost all tests, we are now faster than valgrind 3.10.1.
Details below.
Regtested on x86/amd64/ppc64 (and regtested with all compile time
checks set).
I have also regtested with libreoffice and firefox.
(with firefox, also with CHECK_ZSM set to 1).
Details about performance:
hgtrace = this patch
trunk_untouched = trunk
base_secmap = trunk before secmap GC
valgrind 3.10.1 included for comparison
Measured on core i5 2.53GHz
-- Running tests in perf ----------------------------------------------
-- bigcode1 --
bigcode1 hgtrace :0.14s he: 2.6s (18.4x, -----)
bigcode1 trunk_untouched:0.14s he: 2.6s (18.4x, -0.4%)
bigcode1 base_secmap:0.14s he: 2.6s (18.6x, -1.2%)
bigcode1 valgrind-3.10.1:0.14s he: 2.8s (19.8x, -7.8%)
-- bigcode2 --
bigcode2 hgtrace :0.14s he: 6.3s (44.7x, -----)
bigcode2 trunk_untouched:0.14s he: 6.2s (44.6x, 0.2%)
bigcode2 base_secmap:0.14s he: 6.3s (45.0x, -0.6%)
bigcode2 valgrind-3.10.1:0.14s he: 6.6s (47.1x, -5.4%)
-- bz2 --
bz2 hgtrace :0.64s he:11.3s (17.7x, -----)
bz2 trunk_untouched:0.64s he:11.7s (18.2x, -3.2%)
bz2 base_secmap:0.64s he:11.1s (17.3x, 1.9%)
bz2 valgrind-3.10.1:0.64s he:12.6s (19.7x,-11.3%)
-- fbench --
fbench hgtrace :0.29s he: 3.4s (11.8x, -----)
fbench trunk_untouched:0.29s he: 3.4s (11.7x, 0.6%)
fbench base_secmap:0.29s he: 3.6s (12.4x, -5.0%)
fbench valgrind-3.10.1:0.29s he: 3.5s (12.2x, -3.5%)
-- ffbench --
ffbench hgtrace :0.26s he: 9.8s (37.7x, -----)
ffbench trunk_untouched:0.26s he:10.0s (38.4x, -1.9%)
ffbench base_secmap:0.26s he: 9.8s (37.8x, -0.2%)
ffbench valgrind-3.10.1:0.26s he:10.0s (38.4x, -1.9%)
-- heap --
heap hgtrace :0.11s he: 9.2s (84.0x, -----)
heap trunk_untouched:0.11s he: 9.6s (87.1x, -3.7%)
heap base_secmap:0.11s he: 9.0s (81.9x, 2.5%)
heap valgrind-3.10.1:0.11s he: 9.1s (82.9x, 1.3%)
-- heap_pdb4 --
heap_pdb4 hgtrace :0.13s he:10.7s (82.3x, -----)
heap_pdb4 trunk_untouched:0.13s he:11.0s (84.8x, -3.0%)
heap_pdb4 base_secmap:0.13s he:10.5s (80.8x, 1.8%)
heap_pdb4 valgrind-3.10.1:0.13s he:10.6s (81.8x, 0.7%)
-- many-loss-records --
many-loss-records hgtrace :0.01s he: 1.5s (152.0x, -----)
many-loss-records trunk_untouched:0.01s he: 1.6s (157.0x, -3.3%)
many-loss-records base_secmap:0.01s he: 1.6s (158.0x, -3.9%)
many-loss-records valgrind-3.10.1:0.01s he: 1.7s (167.0x, -9.9%)
-- many-xpts --
many-xpts hgtrace :0.03s he: 2.8s (91.7x, -----)
many-xpts trunk_untouched:0.03s he: 2.8s (94.7x, -3.3%)
many-xpts base_secmap:0.03s he: 2.8s (94.0x, -2.5%)
many-xpts valgrind-3.10.1:0.03s he: 2.9s (97.7x, -6.5%)
-- memrw --
memrw hgtrace :0.06s he: 7.3s (121.2x, -----)
memrw trunk_untouched:0.06s he: 7.2s (120.3x, 0.7%)
memrw base_secmap:0.06s he: 7.1s (117.7x, 2.9%)
memrw valgrind-3.10.1:0.06s he: 8.1s (135.2x,-11.6%)
-- sarp --
sarp hgtrace :0.02s he: 7.6s (378.5x, -----)
sarp trunk_untouched:0.02s he: 8.4s (422.0x,-11.5%)
sarp base_secmap:0.02s he: 8.6s (431.0x,-13.9%)
sarp valgrind-3.10.1:0.02s he: 8.8s (442.0x,-16.8%)
-- tinycc --
tinycc hgtrace :0.20s he:12.4s (62.0x, -----)
tinycc trunk_untouched:0.20s he:12.6s (63.2x, -1.9%)
tinycc base_secmap:0.20s he:12.6s (63.0x, -1.6%)
tinycc valgrind-3.10.1:0.20s he:12.7s (63.5x, -2.3%)
-- Finished tests in perf ----------------------------------------------
== 12 programs, 48 timings =================
Modified:
trunk/helgrind/hg_main.c
trunk/helgrind/libhb_core.c
Modified: trunk/helgrind/hg_main.c
==============================================================================
--- trunk/helgrind/hg_main.c (original)
+++ trunk/helgrind/hg_main.c Fri May 15 12:41:54 2015
@@ -5568,7 +5568,11 @@
VG_(track_die_mem_stack_signal)( evh__die_mem );
VG_(track_die_mem_brk) ( evh__die_mem_munmap );
VG_(track_die_mem_munmap) ( evh__die_mem_munmap );
- VG_(track_die_mem_stack) ( evh__die_mem );
+
+ /* evh__die_mem calls at the end libhb_srange_noaccess_NoFX
+ which has no effect. We do not use VG_(track_die_mem_stack),
+ as this would be an expensive way to do nothing. */
+ // VG_(track_die_mem_stack) ( evh__die_mem );
// FIXME: what is this for?
VG_(track_ban_mem_stack) (NULL);
Modified: trunk/helgrind/libhb_core.c
==============================================================================
--- trunk/helgrind/libhb_core.c (original)
+++ trunk/helgrind/libhb_core.c Fri May 15 12:41:54 2015
@@ -3568,9 +3568,12 @@
}
}
-static void Filter__clear_range ( Filter* fi, Addr a, UWord len )
+/* Only used to verify the fast Filter__clear_range */
+__attribute__((unused))
+static void Filter__clear_range_SLOW ( Filter* fi, Addr a, UWord len )
{
- //VG_(printf)("%lu ", len);
+ tl_assert (CHECK_ZSM);
+
/* slowly do part preceding 8-alignment */
while (UNLIKELY(!VG_IS_8_ALIGNED(a)) && LIKELY(len > 0)) {
Filter__clear_1byte( fi, a );
@@ -3591,6 +3594,151 @@
}
}
+static void Filter__clear_range ( Filter* fi, Addr a, UWord len )
+{
+# if CHECK_ZSM > 0
+ /* We check the below more complex algorithm with the simple one.
+ This check is very expensive : we do first the slow way on a
+ copy of the data, then do it the fast way. On RETURN, we check
+ the two values are equal. */
+ Filter fi_check = *fi;
+ Filter__clear_range_SLOW(&fi_check, a, len);
+# define RETURN goto check_and_return
+# else
+# define RETURN return
+# endif
+
+ Addr begtag = FI_GET_TAG(a); /* tag of range begin */
+
+ Addr end = a + len - 1;
+ Addr endtag = FI_GET_TAG(end); /* tag of range end. */
+
+ UWord rlen = len; /* remaining length to clear */
+
+ Addr c = a; /* Current position we are clearing. */
+ UWord clineno = FI_GET_LINENO(c); /* Current lineno we are clearing */
+ FiLine* cline; /* Current line we are clearing */
+ UWord cloff; /* Current offset in line we are clearing, when clearing
+ partial lines. */
+
+ UShort u16;
+
+ STATIC_ASSERT (FI_LINE_SZB == 32);
+ // Below assumes filter lines are 32 bytes
+
+ if (LIKELY(fi->tags[clineno] == begtag)) {
+ /* LIKELY for the heavy caller VG_(unknown_SP_update). */
+ /* First filter line matches begtag.
+ If c is not at the filter line begin, the below will clear
+ the filter line bytes starting from c. */
+ cline = &fi->lines[clineno];
+ cloff = (c - begtag) / 8;
+
+ /* First the byte(s) needed to reach 8-alignment */
+ if (UNLIKELY(!VG_IS_8_ALIGNED(c))) {
+ /* hiB is the nr of bytes (higher addresses) from c to reach
+ 8-aligment. */
+ UWord hiB = 8 - (c & 7);
+ /* Compute 2-bit/byte mask representing hiB bytes [c..c+hiB[
+ mask is C000 , F000, FC00, FF00, FFC0, FFF0 or FFFC for the byte
+ range 7..7 6..7 5..7 4..7 3..7 2..7 1..7 */
+ UShort mask = 0xFFFF << (16 - 2*hiB);
+
+ u16 = cline->u16s[cloff];
+ if (LIKELY(rlen >= hiB)) {
+ cline->u16s[cloff] = u16 & ~mask; /* clear all hiB from c */
+ rlen -= hiB;
+ c += hiB;
+ cloff += 1;
+ } else {
+ /* Only have the bits for rlen bytes bytes. */
+ mask = mask & ~(0xFFFF << (16 - 2*(hiB-rlen)));
+ cline->u16s[cloff] = u16 & ~mask; /* clear rlen bytes from c. */
+ RETURN; // We have cleared all what we can.
+ }
+ }
+ /* c is now 8 aligned. Clear by 8 aligned bytes,
+ till c is filter-line aligned */
+ while (!VG_IS_32_ALIGNED(c) && rlen >= 8) {
+ cline->u16s[cloff] = 0;
+ c += 8;
+ rlen -= 8;
+ cloff += 1;
+ }
+ } else {
+ c = begtag + FI_LINE_SZB;
+ if (c > end)
+ RETURN; // We have cleared all what we can.
+ rlen -= c - a;
+ }
+ // We have changed c, so re-establish clineno.
+ clineno = FI_GET_LINENO(c);
+
+ if (rlen >= FI_LINE_SZB) {
+ /* Here, c is filter line-aligned. Clear all full lines that
+ overlap with the range starting at c, made of a full lines */
+ UWord nfull = rlen / FI_LINE_SZB;
+ UWord full_len = nfull * FI_LINE_SZB;
+ rlen -= full_len;
+ if (nfull > FI_NUM_LINES)
+ nfull = FI_NUM_LINES; // no need to check several times the same entry.
+
+ for (UWord n = 0; n < nfull; n++) {
+ if (UNLIKELY(address_in_range(fi->tags[clineno], c, full_len))) {
+ cline = &fi->lines[clineno];
+ cline->u16s[0] = 0;
+ cline->u16s[1] = 0;
+ cline->u16s[2] = 0;
+ cline->u16s[3] = 0;
+ STATIC_ASSERT (4 == sizeof(cline->u16s)/sizeof(cline->u16s[0]));
+ }
+ clineno++;
+ if (UNLIKELY(clineno == FI_NUM_LINES))
+ clineno = 0;
+ }
+
+ c += full_len;
+ clineno = FI_GET_LINENO(c);
+ }
+
+ if (CHECK_ZSM) {
+ tl_assert(VG_IS_8_ALIGNED(c));
+ tl_assert(clineno == FI_GET_LINENO(c));
+ }
+
+ /* Do the last filter line, if it was not cleared as a full filter line */
+ if (UNLIKELY(rlen > 0) && fi->tags[clineno] == endtag) {
+ cline = &fi->lines[clineno];
+ cloff = (c - endtag) / 8;
+ if (CHECK_ZSM) tl_assert(FI_GET_TAG(c) == endtag);
+
+ /* c is 8 aligned. Clear by 8 aligned bytes, till we have less than
+ 8 bytes. */
+ while (rlen >= 8) {
+ cline->u16s[cloff] = 0;
+ c += 8;
+ rlen -= 8;
+ cloff += 1;
+ }
+ /* Then the remaining byte(s) */
+ if (rlen > 0) {
+ /* nr of bytes from c to reach end. */
+ UWord loB = rlen;
+ /* Compute mask representing loB bytes [c..c+loB[ :
+ mask is 0003, 000F, 003F, 00FF, 03FF, 0FFF or 3FFF */
+ UShort mask = 0xFFFF >> (16 - 2*loB);
+
+ u16 = cline->u16s[cloff];
+ cline->u16s[cloff] = u16 & ~mask; /* clear all loB from c */
+ }
+ }
+
+# if CHECK_ZSM > 0
+ check_and_return:
+ tl_assert (VG_(memcmp)(&fi_check, fi, sizeof(fi_check)) == 0);
+# endif
+# undef RETURN
+}
/* ------ Read handlers for the filter. ------ */
@@ -6786,7 +6934,7 @@
if (CHECK_ZSM) tl_assert(is_sane_SecMap(sm));
for (UInt lz = 0; lz < N_SECMAP_ZLINES; lz++) {
- if (sm->linesZ[lz].dict[0] != SVal_INVALID)
+ if (LIKELY(sm->linesZ[lz].dict[0] != SVal_INVALID))
rcdec_LineZ(&sm->linesZ[lz]);
}
for (UInt lf = 0; lf < sm->linesF_size; lf++) {
|
|
From: <sv...@va...> - 2015-05-15 09:39:02
|
Author: philippe
Date: Fri May 15 10:38:54 2015
New Revision: 15235
Log:
micro-opt: add an UNLIKELY
Modified:
trunk/helgrind/libhb_core.c
Modified: trunk/helgrind/libhb_core.c
==============================================================================
--- trunk/helgrind/libhb_core.c (original)
+++ trunk/helgrind/libhb_core.c Fri May 15 10:38:54 2015
@@ -1647,7 +1647,7 @@
if (address_in_range(cache_shmem.tags0[ga_ix], ga, szB))
cache_shmem.tags0[ga_ix] = 1/*INVALID*/;
ga_ix++;
- if (ga_ix == N_WAY_NENT)
+ if (UNLIKELY(ga_ix == N_WAY_NENT))
ga_ix = 0;
}
}
|