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
|
|
2
|
3
(4) |
4
(5) |
5
(2) |
6
|
7
(2) |
8
(4) |
|
9
(1) |
10
(7) |
11
(4) |
12
(4) |
13
(8) |
14
(6) |
15
(3) |
|
16
(4) |
17
|
18
|
19
|
20
(6) |
21
|
22
|
|
23
|
24
(1) |
25
(8) |
26
(12) |
27
(1) |
28
(9) |
29
(9) |
|
30
(3) |
31
(4) |
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2010-05-20 08:12:56
|
On Thursday 20 May 2010, Konstantin Serebryany wrote: > Hi, > > I have a test case which will not deadlock, but helgrind reports "lock > order "0x600DA0 before 0x600DE0" violated". > The code does indeed have lock order inversion, but due to reader locks no > deadlock is possible. > I don't have a strong opinion on whether this case should be reported or > not, just want to know what do you think. The lock order checking in Helgrind doesn't understand the difference between reader/writer locks and normal ones, and assumes all locks are normal ones. So it probably can't handle this case properly. Suggestions for a better algorithm welcomed. I think Bart might know more about this .. I remember some mail about this problem some time in the past. J |
|
From: Konstantin S. <kon...@gm...> - 2010-05-20 06:03:17
|
Hi,
I have a test case which will not deadlock, but helgrind reports "lock order
"0x600DA0 before 0x600DE0" violated".
The code does indeed have lock order inversion, but due to reader locks no
deadlock is possible.
I don't have a strong opinion on whether this case should be reported or
not, just want to know what do you think.
Thanks,
--kcc
% cat rd_dl.cc
#include <pthread.h>
pthread_rwlock_t l1, l2;
void *f1(void *) {
pthread_rwlock_wrlock(&l1);
pthread_rwlock_rdlock(&l2);
pthread_rwlock_unlock(&l2);
pthread_rwlock_unlock(&l1);
}
void *f2(void *) {
pthread_rwlock_rdlock(&l2);
pthread_rwlock_wrlock(&l1);
pthread_rwlock_unlock(&l1);
pthread_rwlock_unlock(&l2);
}
int main() {
pthread_t t1, t2;
pthread_rwlock_init(&l1, NULL);
pthread_rwlock_init(&l2, NULL);
pthread_create(&t1, NULL, f1, NULL);
pthread_create(&t2, NULL, f2, NULL);
pthread_join(t1, NULL);
pthread_join(t2, NULL);
}
% g++ -g -lpthread rd_dl.cc
% ~/valgrind/trunk/inst/bin/valgrind --tool=helgrind ./a.out
==26851== Helgrind, a thread error detector
==26851== Copyright (C) 2007-2009, and GNU GPL'd, by OpenWorks LLP et al.
==26851== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
info
==26851== Command: ./a.out
==26851==
==26851== Thread #3 was created
==26851== at 0x58907D0: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
==26851== by 0x4E2A574: pthread_create@@GLIBC_2.2.5 (in
/usr/grte/v1/lib64/libpthread-2.3.6.so)
==26851== by 0x4C21210: pthread_create_WRK (hg_intercepts.c:241)
==26851== by 0x4C212B9: pthread_create@* (hg_intercepts.c:268)
==26851== by 0x400861: main (rd_dl.cc:24)
==26851==
==26851== Thread #3: lock order "0x600DA0 before 0x600DE0" violated
==26851== at 0x4C1ED6F: pthread_rwlock_wrlock (hg_intercepts.c:1380)
==26851== by 0x4008A4: f2(void*) (rd_dl.cc:14)
==26851== by 0x4C21342: mythread_wrapper (hg_intercepts.c:213)
==26851== by 0x4E2A0C9: start_thread (in /usr/grte/v1/lib64/
libpthread-2.3.6.so)
==26851== by 0x5890811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
==26851== Required order was established by acquisition of lock at
0x600DA0
==26851== at 0x4C1ED6F: pthread_rwlock_wrlock (hg_intercepts.c:1380)
==26851== by 0x4008D0: f1(void*) (rd_dl.cc:6)
==26851== by 0x4C21342: mythread_wrapper (hg_intercepts.c:213)
==26851== by 0x4E2A0C9: start_thread (in /usr/grte/v1/lib64/
libpthread-2.3.6.so)
==26851== by 0x5890811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
==26851== followed by a later acquisition of lock at 0x600DE0
==26851== at 0x4C1EEFC: pthread_rwlock_rdlock (hg_intercepts.c:1427)
==26851== by 0x4008DA: f1(void*) (rd_dl.cc:7)
==26851== by 0x4C21342: mythread_wrapper (hg_intercepts.c:213)
==26851== by 0x4E2A0C9: start_thread (in /usr/grte/v1/lib64/
libpthread-2.3.6.so)
==26851== by 0x5890811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so)
|
|
From: Alexander P. <gl...@go...> - 2010-05-16 16:25:25
|
Nightly build on mcgrind ( Darwin 9.8.0 i386 ) Started at 2010-05-16 09:06:00 MSD Ended at 2010-05-16 09:24:50 MSD Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 442 tests, 26 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) none/tests/require-text-symbol-2 (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) drd/tests/circular_buffer (stderr) drd/tests/pth_inconsistent_cond_wait (stderr) drd/tests/sem_open (stderr) drd/tests/sem_open2 (stderr) drd/tests/sem_open3 (stderr) drd/tests/sem_open_traced (stderr) drd/tests/tc17_sembar (stderr) drd/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Alexander P. <gl...@go...> - 2010-05-16 04:13:37
|
Nightly build on mcgrind ( Darwin 9.8.0 i386 ) Started at 2010-05-15 09:06:00 MSD Ended at 2010-05-15 09:25:09 MSD Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 442 tests, 26 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) none/tests/require-text-symbol-2 (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) drd/tests/circular_buffer (stderr) drd/tests/pth_inconsistent_cond_wait (stderr) drd/tests/sem_open (stderr) drd/tests/sem_open2 (stderr) drd/tests/sem_open3 (stderr) drd/tests/sem_open_traced (stderr) drd/tests/tc17_sembar (stderr) drd/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-05-16 02:49:50
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-05-16 03:05:07 BST Ended at 2010-05-16 03:49:34 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 541 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-05-16 02:36:33
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-05-16 03:10:04 BST Ended at 2010-05-16 03:36:10 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 548 tests, 2 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 548 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun May 16 03:23:17 2010 --- new.short Sun May 16 03:36:10 2010 *************** *** 8,10 **** ! == 548 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) --- 8,11 ---- ! == 548 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) |
|
From: <sv...@va...> - 2010-05-15 08:37:33
|
Author: bart
Date: 2010-05-15 09:37:24 +0100 (Sat, 15 May 2010)
New Revision: 11132
Log:
Changes:
- Made glibc version detection test shorter and faster.
- Made unsupported glibc version error message more detailed.
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2010-05-14 11:18:52 UTC (rev 11131)
+++ trunk/configure.in 2010-05-15 08:37:24 UTC (rev 11132)
@@ -39,6 +39,7 @@
# AC_SUBST([OBJCFLAGS])
# ])
AC_PROG_RANLIB
+AC_PROG_SED
# If no AR variable was specified, look up the name of the archiver. Otherwise
# do not touch the AR variable.
@@ -582,118 +583,19 @@
# This variable will collect the suppression files to be used.
AC_SUBST(DEFAULT_SUPP)
-GLIBC_VERSION=""
+AC_CHECK_HEADER([features.h])
-AC_EGREP_CPP([GLIBC_22], [
+if test x$ac_cv_header_features_h = xyes; then
+ rm -f conftest.$ac_ext
+ cat <<_ACEOF >conftest.$ac_ext
#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2)
- GLIBC_22
- #endif
+#if defined(__GNU_LIBRARY__) && defined(__GLIBC__) && defined(__GLIBC_MINOR__)
+glibc version is: __GLIBC__ __GLIBC_MINOR__
#endif
-],
-GLIBC_VERSION="2.2")
+_ACEOF
+ GLIBC_VERSION="`$CPP conftest.$ac_ext | $SED -n 's/^glibc version is: //p' | $SED 's/ /./g'`"
+fi
-AC_EGREP_CPP([GLIBC_23], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 3)
- GLIBC_23
- #endif
-#endif
-],
-GLIBC_VERSION="2.3")
-
-AC_EGREP_CPP([GLIBC_24], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 4)
- GLIBC_24
- #endif
-#endif
-],
-GLIBC_VERSION="2.4")
-
-AC_EGREP_CPP([GLIBC_25], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 5)
- GLIBC_25
- #endif
-#endif
-],
-GLIBC_VERSION="2.5")
-
-AC_EGREP_CPP([GLIBC_26], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 6)
- GLIBC_26
- #endif
-#endif
-],
-GLIBC_VERSION="2.6")
-
-AC_EGREP_CPP([GLIBC_27], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 7)
- GLIBC_27
- #endif
-#endif
-],
-GLIBC_VERSION="2.7")
-
-AC_EGREP_CPP([GLIBC_28], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 8)
- GLIBC_28
- #endif
-#endif
-],
-GLIBC_VERSION="2.8")
-
-AC_EGREP_CPP([GLIBC_29], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 9)
- GLIBC_29
- #endif
-#endif
-],
-GLIBC_VERSION="2.9")
-
-AC_EGREP_CPP([GLIBC_210], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 10)
- GLIBC_210
- #endif
-#endif
-],
-GLIBC_VERSION="2.10")
-
-AC_EGREP_CPP([GLIBC_211], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 11)
- GLIBC_211
- #endif
-#endif
-],
-GLIBC_VERSION="2.11")
-
-AC_EGREP_CPP([GLIBC_212], [
-#include <features.h>
-#ifdef __GNU_LIBRARY__
- #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 12)
- GLIBC_212
- #endif
-#endif
-],
-GLIBC_VERSION="2.12")
-
AC_EGREP_CPP([AIX5_LIBC], [
#include <standards.h>
#if defined(_AIXVERSION_510) || defined(_AIXVERSION_520) || defined(_AIXVERSION_530)
@@ -806,7 +708,7 @@
;;
*)
- AC_MSG_RESULT(unsupported version)
+ AC_MSG_RESULT([unsupported version ${GLIBC_VERSION}])
AC_MSG_ERROR([Valgrind requires glibc version 2.2 - 2.12])
AC_MSG_ERROR([or AIX 5.1 or 5.2 or 5.3 GLIBC_VERSION])
AC_MSG_ERROR([or Darwin libc])
|
|
From: Tom H. <th...@cy...> - 2010-05-15 02:49:57
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-05-15 03:05:10 BST Ended at 2010-05-15 03:49:39 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 541 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-05-15 02:36:22
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-05-15 03:10:05 BST Ended at 2010-05-15 03:36:07 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 548 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 548 tests, 2 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat May 15 03:23:20 2010 --- new.short Sat May 15 03:36:07 2010 *************** *** 8,11 **** ! == 548 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) --- 8,10 ---- ! == 548 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Scott P. <pa...@la...> - 2010-05-14 16:23:00
|
Julian, > So, my answer from yesterday stands: in this case, if you have an > "IRTemp t" where t is "t4" in your code, then you need to pass > the arg "mkexpr(t)" as the relevant component of mkIRExprVec_N that > you use to prepare the args for the call. Thanks; that seems to work. (I just wanted to make sure I wasn't misinterpreting the data I was getting.) > You are going to run into problems with the IR optimiser, which runs > before the IR gets to your instrumenter. It aggressively does the > following things w.r.t. gets and puts (reads/writes of the guest > register state): Got it. Fortunately, in my tool's case, those IR optimizations shouldn't pose a problem. Thanks for the detailed explanation, -- Scott |
|
From: <sv...@va...> - 2010-05-14 11:19:03
|
Author: sewardj Date: 2010-05-14 12:18:52 +0100 (Fri, 14 May 2010) New Revision: 11131 Log: Add missing backslash. Modified: trunk/none/tests/Makefile.am Modified: trunk/none/tests/Makefile.am =================================================================== --- trunk/none/tests/Makefile.am 2010-05-13 08:10:52 UTC (rev 11130) +++ trunk/none/tests/Makefile.am 2010-05-14 11:18:52 UTC (rev 11131) @@ -114,7 +114,7 @@ readline1.stderr.exp readline1.stdout.exp \ readline1.vgtest \ require-text-symbol-1.vgtest \ - require-text-symbol-1.stderr.exp + require-text-symbol-1.stderr.exp \ require-text-symbol-2.vgtest \ require-text-symbol-2.stderr.exp-libcso6 \ res_search.stderr.exp res_search.stdout.exp res_search.vgtest \ |
|
From: Julian S. <js...@ac...> - 2010-05-14 08:00:43
|
> I'm not sure I understand this. Maybe I didn't ask my question > correctly so let me try again: If my instrumentation code sees > > t3 = 0x1000 > t4 = Add32(t3, 0x234) > t5 = GETI(128:8xI8)[t4,-1] > > then I want the handler function to get passed 0x1234. Is 0x1234 what > you mean by a value/simulated register contents? Yes. > If so, then what do > I put in my instrumentation code to ensure that the handler sees that > 0x1234? So, my answer from yesterday stands: in this case, if you have an "IRTemp t" where t is "t4" in your code, then you need to pass the arg "mkexpr(t)" as the relevant component of mkIRExprVec_N that you use to prepare the args for the call. That said ... ---------- > I'm just keeping track of which register bytes have been read when. > I'm not actually modifying any part of guest state. You are going to run into problems with the IR optimiser, which runs before the IR gets to your instrumenter. It aggressively does the following things w.r.t. gets and puts (reads/writes of the guest register state): * redundant-Get removal t1 = Get(ty, off); ...; t2 = Get(ty, off) ==> t1 = Get(ty, off); ...; t2 = t1 provided there are no intervening Puts to the same area in the "..." * redundant-Put removal Put(off) = e1; ...; Put(off) = e2 ==> Put(off) = e2 provided, uh, the second Put postdominates the first Put, and there are no Gets of the area in the "..." * Put-Get forwarding Put(off) = e1; ...; t2 = Get(off,ty) ==> ttemp = e1; Put(off) = ttemp; ...; t2 = ttemp; provided there are no Puts of the area in the "..." There is related trickery GetI/PutI, which are Get/Put variants in which the accessed area is not known until run time. This is needed to model rotating register arrays, like the x87 FPU stack. Anyway, the longer the superblock, the more effective the above are. J |
|
From: Alexander P. <gl...@go...> - 2010-05-14 06:57:22
|
Nightly build on mcgrind ( Darwin 9.8.0 i386 ) Started at 2010-05-14 09:06:00 MSD Ended at 2010-05-14 09:24:54 MSD Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 442 tests, 26 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) none/tests/require-text-symbol-2 (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) drd/tests/circular_buffer (stderr) drd/tests/pth_inconsistent_cond_wait (stderr) drd/tests/sem_open (stderr) drd/tests/sem_open2 (stderr) drd/tests/sem_open3 (stderr) drd/tests/sem_open_traced (stderr) drd/tests/tc17_sembar (stderr) drd/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-05-14 02:50:19
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-05-14 03:05:08 BST Ended at 2010-05-14 03:50:08 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 541 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-05-14 02:36:21
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-05-14 03:10:05 BST Ended at 2010-05-14 03:36:09 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 548 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Scott P. <pa...@la...> - 2010-05-13 22:06:02
|
Julian,
Thanks for the prompt response!
> Passing the identity of bits of the guest state to helper functions
> is pretty dangerous; you need to be careful to tell the IR optimiser
> that that whole section of the guest state can change in arbitrary ways.
I'm just keeping track of which register bytes have been read when.
I'm not actually modifying any part of guest state.
> It's safer to pass values (simulated register contents, really)
> to helper functions.
I'm not sure I understand this. Maybe I didn't ask my question
correctly so let me try again: If my instrumentation code sees
t3 = 0x1000
t4 = Add32(t3, 0x234)
t5 = GETI(128:8xI8)[t4,-1]
then I want the handler function to get passed 0x1234. Is 0x1234 what
you mean by a value/simulated register contents? If so, then what do
I put in my instrumentation code to ensure that the handler sees that
0x1234?
-- Scott
|
|
From: Julian S. <js...@ac...> - 2010-05-13 20:35:36
|
On Thursday 13 May 2010, Scott Pakin wrote:
> I'm writing my first Valgrind tool, and I'm baffled about how to pass
> a GetI.ix to an execution-time function. For example, if at
> instrumentation time I encounter a GETI(128:8xI8)[t1,0] expression,
> how can I ensure that the function call I insert receives the
> *contents* of the t1 temporary when called?
>
> IRSB* myinstrumenter(...)
> {
> ...
> IRExpr* myGetIexpr;
> ...
Let's say that you have (at jit time) some "IRTemp t", which
holds the identity of t1. Then
> dcall_argv = mkIRExprVec_1(<WHAT GOES HERE?>)
mkIRExprVec_1( mkexpr(t) )
> dcall = unsafeIRDirty_0_N(0, "myfunction",
> VG_(fnptr_to_fnentry)(&myfunction),
> dcall_argv);
> addStmtToIRSB(sbOut, IRStmt_Dirty(dcall));
> ...
> }
>
> void myfunction(<WHAT GOES HERE?> ixValue)
Word ixValue
> {
> ...
> }
(Word is a signed machine word)
Passing the identity of bits of the guest state to helper functions
is pretty dangerous; you need to be careful to tell the IR optimiser
that that whole section of the guest state can change in arbitrary ways.
It's safer to pass values (simulated register contents, really)
to helper functions. FWIW, the guest state section denoted by
(128:8xI8) is the tag array for the x87 register stack, which I doubt
contains anything much interesting anyway.
J
|
|
From: Scott P. <pa...@la...> - 2010-05-13 20:14:33
|
I'm writing my first Valgrind tool, and I'm baffled about how to pass
a GetI.ix to an execution-time function. For example, if at
instrumentation time I encounter a GETI(128:8xI8)[t1,0] expression,
how can I ensure that the function call I insert receives the
*contents* of the t1 temporary when called?
IRSB* myinstrumenter(...)
{
...
IRExpr* myGetIexpr;
...
dcall_argv = mkIRExprVec_1(<WHAT GOES HERE?>)
dcall = unsafeIRDirty_0_N(0, "myfunction",
VG_(fnptr_to_fnentry)(&myfunction),
dcall_argv);
addStmtToIRSB(sbOut, IRStmt_Dirty(dcall));
...
}
void myfunction(<WHAT GOES HERE?> ixValue)
{
...
}
Thanks in advance,
-- Scott
|
|
From: <sv...@va...> - 2010-05-13 08:11:00
|
Author: bart
Date: 2010-05-13 09:10:52 +0100 (Thu, 13 May 2010)
New Revision: 11130
Log:
Added an additional tl_assert() statement.
Modified:
trunk/drd/drd_semaphore.c
Modified: trunk/drd/drd_semaphore.c
===================================================================
--- trunk/drd/drd_semaphore.c 2010-05-13 06:32:36 UTC (rev 11129)
+++ trunk/drd/drd_semaphore.c 2010-05-13 08:10:52 UTC (rev 11130)
@@ -337,6 +337,7 @@
{
struct semaphore_info* p;
+ tl_assert(semaphore < semaphore + 1);
p = drd_semaphore_get_or_allocate(semaphore);
tl_assert(p);
p->waiters++;
|
|
From: Alexander P. <gl...@go...> - 2010-05-13 07:31:35
|
Nightly build on mcgrind ( Darwin 9.8.0 i386 ) Started at 2010-05-13 09:06:00 MSD Ended at 2010-05-13 09:24:41 MSD Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 442 tests, 26 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) none/tests/require-text-symbol-2 (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) drd/tests/circular_buffer (stderr) drd/tests/pth_inconsistent_cond_wait (stderr) drd/tests/sem_open (stderr) drd/tests/sem_open2 (stderr) drd/tests/sem_open3 (stderr) drd/tests/sem_open_traced (stderr) drd/tests/tc17_sembar (stderr) drd/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: <sv...@va...> - 2010-05-13 06:32:45
|
Author: bart
Date: 2010-05-13 07:32:36 +0100 (Thu, 13 May 2010)
New Revision: 11129
Log:
Added support for glibc 2.12.
Note: many Helgrind and DRD regression tests still fail on Fedora 13 because
of differences in the call stacks of error reports compared to earlier
glibc/gcc combinations.
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2010-05-12 10:01:32 UTC (rev 11128)
+++ trunk/configure.in 2010-05-13 06:32:36 UTC (rev 11129)
@@ -684,6 +684,16 @@
],
GLIBC_VERSION="2.11")
+AC_EGREP_CPP([GLIBC_212], [
+#include <features.h>
+#ifdef __GNU_LIBRARY__
+ #if (__GLIBC__ == 2 && __GLIBC_MINOR__ == 12)
+ GLIBC_212
+ #endif
+#endif
+],
+GLIBC_VERSION="2.12")
+
AC_EGREP_CPP([AIX5_LIBC], [
#include <standards.h>
#if defined(_AIXVERSION_510) || defined(_AIXVERSION_520) || defined(_AIXVERSION_530)
@@ -776,6 +786,13 @@
DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
DEFAULT_SUPP="glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
DEFAULT_SUPP="glibc-2.X-drd.supp ${DEFAULT_SUPP}"
+ ;;
+ 2.12)
+ AC_MSG_RESULT(2.12 family)
+ AC_DEFINE([GLIBC_2_12], 1, [Define to 1 if you're using glibc 2.12.x])
+ DEFAULT_SUPP="glibc-2.X.supp ${DEFAULT_SUPP}"
+ DEFAULT_SUPP="glibc-2.34567-NPTL-helgrind.supp ${DEFAULT_SUPP}"
+ DEFAULT_SUPP="glibc-2.X-drd.supp ${DEFAULT_SUPP}"
;;
aix5)
AC_MSG_RESULT(AIX 5.1 or 5.2 or 5.3)
@@ -790,7 +807,7 @@
*)
AC_MSG_RESULT(unsupported version)
- AC_MSG_ERROR([Valgrind requires glibc version 2.2 - 2.11])
+ AC_MSG_ERROR([Valgrind requires glibc version 2.2 - 2.12])
AC_MSG_ERROR([or AIX 5.1 or 5.2 or 5.3 GLIBC_VERSION])
AC_MSG_ERROR([or Darwin libc])
;;
|
|
From: Tom H. <th...@cy...> - 2010-05-13 02:45:39
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-05-13 03:05:05 BST Ended at 2010-05-13 03:45:20 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 541 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-05-13 02:36:20
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-05-13 03:10:05 BST Ended at 2010-05-13 03:36:08 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 548 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 548 tests, 2 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu May 13 03:23:18 2010 --- new.short Thu May 13 03:36:08 2010 *************** *** 8,11 **** ! == 548 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) --- 8,10 ---- ! == 548 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Konstantin S. <kon...@gm...> - 2010-05-12 11:23:32
|
On Wed, May 12, 2010 at 12:22 PM, Julian Seward <js...@ac...> wrote: > > > However, I think add_to_freed_queue() could first check and call > > VG_(free) only if it's not custom-allocated. Care to file a bug? > > Kostya, can you give it a try, see if that helps? On simple cases it seems to help. Filed a bug: https://bugs.kde.org/show_bug.cgi?id=237371 --kcc > Also, filing a bug > to track this with would be good. > > I actually already grappled with this problem some weeks back, and I > have a patch which "fixes" it, by keeping a journal of the last 16k > AllocCustom blocks freed, and looking in that to get the required > information if everything else fails. But it's inelegant (yet another > data structure) and slow. I will put the patch on the bug report if > you file one :-) > > J > |
|
From: <sv...@va...> - 2010-05-12 10:01:43
|
Author: bart
Date: 2010-05-12 11:01:32 +0100 (Wed, 12 May 2010)
New Revision: 11128
Log:
DRD: added a suppression pattern for the libstdc++ included with gcc 4.4.4.
Modified:
trunk/glibc-2.X-drd.supp
Modified: trunk/glibc-2.X-drd.supp
===================================================================
--- trunk/glibc-2.X-drd.supp 2010-05-10 20:53:28 UTC (rev 11127)
+++ trunk/glibc-2.X-drd.supp 2010-05-12 10:01:32 UTC (rev 11128)
@@ -41,6 +41,14 @@
# fun:_ZNSsC1ERKSs
# }
+{
+ drd-libstdc++-cxa_guard_release
+ drd:CondErr
+ fun:pthread_cond_broadcast@*
+ fun:__cxa_guard_release
+}
+
+
#
# Suppression patterns for libpthread.
#
|