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
(12) |
2
(9) |
|
3
(23) |
4
(24) |
5
(9) |
6
(7) |
7
(5) |
8
(2) |
9
(6) |
|
10
(5) |
11
(3) |
12
(11) |
13
(4) |
14
|
15
(3) |
16
(4) |
|
17
(3) |
18
(6) |
19
|
20
(1) |
21
(9) |
22
(8) |
23
(1) |
|
24
|
25
(2) |
26
(3) |
27
(16) |
28
(17) |
29
(22) |
30
(7) |
|
31
(4) |
|
|
|
|
|
|
|
From: Konstantin S. <kon...@gm...> - 2010-01-28 19:17:41
|
ahhh.
I again forgot that pthread_barrier is cyclic (resettable).
imho this is error prone and dull, but that's what we have.
I think we will need two annotations to fully support it:
// inserted before the actual barrier_init code
ANNOTATE_CYCLIC_BARRIER_INIT(obj, n)
// inserted before the actual barrier_wait code.
ANNOTATE_CYCLIC_BARRIER_WAIT(obj)
I'll give it a bite on Fri or Mon.
--kcc
On Thu, Jan 28, 2010 at 8:45 PM, Julian Seward <js...@ac...> wrote:
> On Thursday 28 January 2010, Julian Seward wrote:
> > > Yeaaa.
> > > Still, I want a unit test were the current implementation hides a race.
> > > W/o a unittest, how do we test that the new implementation is correct
> (or
> > > at least better)?
> >
> > Fair enough.
> >
> > Something like this [...]
>
> Demo program using libpthread is below.
>
> Helgrind(trunk) says
>
> ==15851== Possible data race during write of size 4 at 0x601060 by thread
> #4
> ==15851== at 0x4007D8: actions_b1 (pthb_reuse_race.c:34)
> ==15851== by 0x4C29752: mythread_wrapper (hg_intercepts.c:202)
> ==15851== by 0x4E3403F: start_thread (in /lib64/libpthread-2.8.so)
> ==15851== by 0x511C08C: clone (in /lib64/libc-2.8.so)
> ==15851== This conflicts with a previous write of size 4 by thread #2
> ==15851== at 0x400812: actions_a1 (pthb_reuse_race.c:19)
> ==15851== by 0x4C29752: mythread_wrapper (hg_intercepts.c:202)
> ==15851== by 0x4E3403F: start_thread (in /lib64/libpthread-2.8.so)
> ==15851== by 0x511C08C: clone (in /lib64/libc-2.8.so)
>
> DRD(trunk) doesn't say anything.
>
> TSan also doesn't say anything.
>
> J
>
>
>
> #define _GNU_SOURCE
>
> #include <assert.h>
> #include <pthread.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> /* Shared location, accessed by A1 (or A2) and B1 (or B2) */
> int L;
>
> /* The barrier, size 2 */
> pthread_barrier_t B;
>
>
> // A1/A2: write L, then wait for barrier, then sleep
> void* actions_a1 ( void* v ) {
> L = 1;
> pthread_barrier_wait(&B);
> sleep(1);
> return NULL;
> }
> void* actions_a2 ( void* v ) {
> pthread_barrier_wait(&B);
> sleep(1);
> return NULL;
> }
>
> // B1/B2: sleep, wait for barrier, then write L
> void* actions_b1 ( void* v ) {
> sleep(1);
> pthread_barrier_wait(&B);
> L = 1;
> return NULL;
> }
> void* actions_b2 ( void* v ) {
> sleep(1);
> pthread_barrier_wait(&B);
> return NULL;
> }
>
>
> int main ( void )
> {
> pthread_t a1, a2, b1, b2;
> pthread_barrier_init(&B, NULL, 2);
>
> pthread_create(&a1, NULL, actions_a1, NULL);
> pthread_create(&a2, NULL, actions_a2, NULL);
> pthread_create(&b1, NULL, actions_b1, NULL);
> pthread_create(&b2, NULL, actions_b2, NULL);
>
> pthread_join(a1, NULL);
> pthread_join(a2, NULL);
> pthread_join(b1, NULL);
> pthread_join(b2, NULL);
>
> return 0;
> }
>
|
|
From: Julian S. <js...@ac...> - 2010-01-28 17:31:06
|
On Thursday 28 January 2010, Julian Seward wrote:
> > Yeaaa.
> > Still, I want a unit test were the current implementation hides a race.
> > W/o a unittest, how do we test that the new implementation is correct (or
> > at least better)?
>
> Fair enough.
>
> Something like this [...]
Demo program using libpthread is below.
Helgrind(trunk) says
==15851== Possible data race during write of size 4 at 0x601060 by thread #4
==15851== at 0x4007D8: actions_b1 (pthb_reuse_race.c:34)
==15851== by 0x4C29752: mythread_wrapper (hg_intercepts.c:202)
==15851== by 0x4E3403F: start_thread (in /lib64/libpthread-2.8.so)
==15851== by 0x511C08C: clone (in /lib64/libc-2.8.so)
==15851== This conflicts with a previous write of size 4 by thread #2
==15851== at 0x400812: actions_a1 (pthb_reuse_race.c:19)
==15851== by 0x4C29752: mythread_wrapper (hg_intercepts.c:202)
==15851== by 0x4E3403F: start_thread (in /lib64/libpthread-2.8.so)
==15851== by 0x511C08C: clone (in /lib64/libc-2.8.so)
DRD(trunk) doesn't say anything.
TSan also doesn't say anything.
J
#define _GNU_SOURCE
#include <assert.h>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
/* Shared location, accessed by A1 (or A2) and B1 (or B2) */
int L;
/* The barrier, size 2 */
pthread_barrier_t B;
// A1/A2: write L, then wait for barrier, then sleep
void* actions_a1 ( void* v ) {
L = 1;
pthread_barrier_wait(&B);
sleep(1);
return NULL;
}
void* actions_a2 ( void* v ) {
pthread_barrier_wait(&B);
sleep(1);
return NULL;
}
// B1/B2: sleep, wait for barrier, then write L
void* actions_b1 ( void* v ) {
sleep(1);
pthread_barrier_wait(&B);
L = 1;
return NULL;
}
void* actions_b2 ( void* v ) {
sleep(1);
pthread_barrier_wait(&B);
return NULL;
}
int main ( void )
{
pthread_t a1, a2, b1, b2;
pthread_barrier_init(&B, NULL, 2);
pthread_create(&a1, NULL, actions_a1, NULL);
pthread_create(&a2, NULL, actions_a2, NULL);
pthread_create(&b1, NULL, actions_b1, NULL);
pthread_create(&b2, NULL, actions_b2, NULL);
pthread_join(a1, NULL);
pthread_join(a2, NULL);
pthread_join(b1, NULL);
pthread_join(b2, NULL);
return 0;
}
|
|
From: Alexander P. <gl...@go...> - 2010-01-28 15:58:38
|
Hi all,
Debugging some test under Valgrind on ARM I've noticed that VEX
handles some vmov instructions incorrectly on that platform.
In particular, VMOV dM, rD, rN handler relies on the fact that (opcode
& 0x0ff00ff0) == 0x0c400b10 (see VEX/priv/guest_arm_toIR.c)
This is ok for dM in the range from d0 to d15, but for d16..d31 it is
just incorrect:
8410: ec400b30 vmov d16, r0, r0
8414: ec400b31 vmov d17, r0, r0
8418: ec400b32 vmov d18, r0, r0
841c: ec400b33 vmov d19, r0, r0
8420: ec400b34 vmov d20, r0, r0
8424: ec400b35 vmov d21, r0, r0
8428: ec400b36 vmov d22, r0, r0
842c: ec400b37 vmov d23, r0, r0
8430: ec400b38 vmov d24, r0, r0
8434: ec400b38 vmov d24, r0, r0
8438: ec400b39 vmov d25, r0, r0
843c: ec400b3a vmov d26, r0, r0
8440: ec400b3b vmov d27, r0, r0
8444: ec400b3c vmov d28, r0, r0
8448: ec400b3d vmov d29, r0, r0
844c: ec400b3e vmov d30, r0, r0
8450: ec400b3f vmov d31, r0, r0
(a piece of objdump -d output)
After fixing this locally I've bumped into several assertions that
relied on the fact the Dreg number is less than 16.
I am sure I can just copy and paste code to double the number of
D-registers in VEX, but won't it break anything?
Thanks,
Alexander Potapenko
Software Engineer
Google Moscow
|
|
From: Julian S. <js...@ac...> - 2010-01-28 15:33:55
|
> Yeaaa.
> Still, I want a unit test were the current implementation hides a race.
> W/o a unittest, how do we test that the new implementation is correct (or
> at least better)?
Fair enough.
Something like this
4 threads, call them A1 A2 B1 and B2
1 barrier B of size 2
1 shared location L
All 4 threads created
B1 and B2 sleep(1)
A1 (or A2) writes to L
A1 and A2 do pthread_barrier_wait(B)
A1 and A2 sleep(1)
now B1 and B2 wake up. They do pthread_barrier_wait(B), thereby
falsely acquiring dependencies on A1 and A2's previous use of B
B1 (or B2) writes to L. This is really a race, but not detected due
to the false dependencies.
All 4 threads pth_join back to waiting parent.
Does that make sense? I think it should demonstrate the problem.
> There are two which are broken, I need to get rid of them.
> ANNOTATE_UNPUBLISH... is completely broken (bad idea)
> ANNOTATE_PUBLISH... is broken in case we are using literace-like sampling
I'll delete them in helgrind.h then.
J
|
|
From: <sv...@va...> - 2010-01-28 15:24:04
|
Author: sewardj
Date: 2010-01-28 15:23:54 +0000 (Thu, 28 Jan 2010)
New Revision: 11032
Log:
Followup fix to r11006. Don't pass va_list by value through client
requests, since there's no guarantee it is the same size as a machine
word.
This renames the private client request VG_USERREQ__INTERNAL_PRINTF to
VG_USERREQ__INTERNAL_PRINTF_VALIST_BY_REF and changes the
argument-passing accordingly.
The public client requests VG_USERREQ__PRINTF and
VG_USERREQ__PRINTF_BACKTRACE are now deprecated, and handled only in
the case where sizeof(UWord) == sizeof(va_list). In all other cases V
will now print a detailed error message and abort. This breaks binary
compatibility of apps compiled using VALGRIND_PRINTF and
VALGRIND_PRINTF_BACKTRACE, but that's not easy to avoid.
VG_USERREQ__PRINTF and VG_USERREQ__PRINTF_BACKTRACE are now replaced
by VG_USERREQ__PRINTF_VALIST_BY_REF and
VG_USERREQ__PRINTF_BACKTRACE_VALIST_BY_REF. The end-user macros
VALGRIND_PRINTF and VALGRIND_PRINTF_BACKTRACE have been adjusted to
use these new requests instead.
Overall result is that source level compatibility of code using
VALGRIND_PRINTF{,_BACKTRACE} is retained, but binary level
compatibility may be broken, necessitating a rebuild of code using
these macros.
Modified:
trunk/coregrind/m_scheduler/scheduler.c
trunk/coregrind/pub_core_clreq.h
trunk/include/valgrind.h
Modified: trunk/coregrind/m_scheduler/scheduler.c
===================================================================
--- trunk/coregrind/m_scheduler/scheduler.c 2010-01-27 10:28:00 UTC (rev 11031)
+++ trunk/coregrind/m_scheduler/scheduler.c 2010-01-28 15:23:54 UTC (rev 11032)
@@ -1408,50 +1408,73 @@
break;
case VG_USERREQ__PRINTF: {
+ /* JRS 2010-Jan-28: this is DEPRECATED; use the
+ _VALIST_BY_REF version instead */
+ if (sizeof(va_list) != sizeof(UWord))
+ goto va_list_casting_error_NORETURN;
union {
va_list vargs;
- unsigned long ul;
- } args;
- Int count;
- args.ul = (unsigned long)arg[2];
- count =
- VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], args.vargs );
- VG_(message_flush)();
- SET_CLREQ_RETVAL( tid, count );
- break; }
+ unsigned long uw;
+ } u;
+ u.uw = (unsigned long)arg[2];
+ Int count =
+ VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], u.vargs );
+ VG_(message_flush)();
+ SET_CLREQ_RETVAL( tid, count );
+ break;
+ }
- case VG_USERREQ__INTERNAL_PRINTF: {
+ case VG_USERREQ__PRINTF_BACKTRACE: {
+ /* JRS 2010-Jan-28: this is DEPRECATED; use the
+ _VALIST_BY_REF version instead */
+ if (sizeof(va_list) != sizeof(UWord))
+ goto va_list_casting_error_NORETURN;
union {
va_list vargs;
- unsigned long ul;
- } args;
- Int count;
- args.ul = (unsigned long)arg[2];
- count =
- VG_(vmessage)( Vg_DebugMsg, (char *)arg[1], args.vargs );
- VG_(message_flush)();
- SET_CLREQ_RETVAL( tid, count );
- break; }
+ unsigned long uw;
+ } u;
+ u.uw = (unsigned long)arg[2];
+ Int count =
+ VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], u.vargs );
+ VG_(message_flush)();
+ VG_(get_and_pp_StackTrace)( tid, VG_(clo_backtrace_size) );
+ SET_CLREQ_RETVAL( tid, count );
+ break;
+ }
+ case VG_USERREQ__PRINTF_VALIST_BY_REF: {
+ va_list* vargsp = (va_list*)arg[2];
+ Int count =
+ VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], *vargsp );
+ VG_(message_flush)();
+ SET_CLREQ_RETVAL( tid, count );
+ break;
+ }
+
+ case VG_USERREQ__PRINTF_BACKTRACE_VALIST_BY_REF: {
+ va_list* vargsp = (va_list*)arg[2];
+ Int count =
+ VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], *vargsp );
+ VG_(message_flush)();
+ VG_(get_and_pp_StackTrace)( tid, VG_(clo_backtrace_size) );
+ SET_CLREQ_RETVAL( tid, count );
+ break;
+ }
+
+ case VG_USERREQ__INTERNAL_PRINTF_VALIST_BY_REF: {
+ va_list* vargsp = (va_list*)arg[2];
+ Int count =
+ VG_(vmessage)( Vg_DebugMsg, (char *)arg[1], *vargsp );
+ VG_(message_flush)();
+ SET_CLREQ_RETVAL( tid, count );
+ break;
+ }
+
case VG_USERREQ__ADD_IFUNC_TARGET: {
VG_(redir_add_ifunc_target)( arg[1], arg[2] );
SET_CLREQ_RETVAL( tid, 0);
break; }
- case VG_USERREQ__PRINTF_BACKTRACE: {
- union {
- va_list vargs;
- unsigned long ul;
- } args;
- Int count;
- args.ul = (unsigned long)arg[2];
- count =
- VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], args.vargs );
- VG_(message_flush)();
- VG_(get_and_pp_StackTrace)( tid, VG_(clo_backtrace_size) );
- SET_CLREQ_RETVAL( tid, count );
- break; }
-
case VG_USERREQ__STACK_REGISTER: {
UWord sid = VG_(register_stack)((Addr)arg[1], (Addr)arg[2]);
SET_CLREQ_RETVAL( tid, sid );
@@ -1555,6 +1578,32 @@
}
break;
}
+ return;
+
+ /*NOTREACHED*/
+ va_list_casting_error_NORETURN:
+ VG_(umsg)(
+ "Valgrind: fatal error - cannot continue: use of the deprecated\n"
+ "client requests VG_USERREQ__PRINTF or VG_USERREQ__PRINTF_BACKTRACE\n"
+ "on a platform where they cannot be supported. Please use the\n"
+ "equivalent _VALIST_BY_REF versions instead.\n"
+ "\n"
+ "This is a binary-incompatible change in Valgrind's client request\n"
+ "mechanism. It is unfortunate, but difficult to avoid. End-users\n"
+ "are expected to almost never see this message. The only case in\n"
+ "which you might see this message is if your code uses the macros\n"
+ "VALGRIND_PRINTF or VALGRIND_PRINTF_BACKTRACE. If so, you will need\n"
+ "to recompile such code, using the header files from this version of\n"
+ "Valgrind, and not any previous version.\n"
+ "\n"
+ "If you see this mesage in any other circumstances, it is probably\n"
+ "a bug in Valgrind. In this case, please file a bug report at\n"
+ "\n"
+ " http://www.valgrind.org/support/bug_reports.html\n"
+ "\n"
+ "Will now abort.\n"
+ );
+ vg_assert(0);
}
Modified: trunk/coregrind/pub_core_clreq.h
===================================================================
--- trunk/coregrind/pub_core_clreq.h 2010-01-27 10:28:00 UTC (rev 11031)
+++ trunk/coregrind/pub_core_clreq.h 2010-01-28 15:23:54 UTC (rev 11032)
@@ -47,8 +47,8 @@
/* Get the tool's malloc-wrapping functions */
VG_USERREQ__GET_MALLOCFUNCS = 0x3030,
- /* Internal equivalent of VALGRIND_PRINTF . */
- VG_USERREQ__INTERNAL_PRINTF = 0x3103,
+ /* Internal equivalent of VALGRIND_PRINTF_VALIST_BY_REF . */
+ VG_USERREQ__INTERNAL_PRINTF_VALIST_BY_REF = 0x3103,
/* Add a target for an indirect function redirection. */
VG_USERREQ__ADD_IFUNC_TARGET = 0x3104,
@@ -64,16 +64,13 @@
static int VALGRIND_INTERNAL_PRINTF(const char *format, ...)
{
unsigned long _qzz_res = 0;
- union {
- va_list vargs;
- unsigned long ul;
- } args;
- va_start(args.vargs, format);
+ va_list vargs;
+ va_start(vargs, format);
VALGRIND_DO_CLIENT_REQUEST(
- _qzz_res, 0, VG_USERREQ__INTERNAL_PRINTF,
- (unsigned long)format, (unsigned long)(args.ul), 0, 0, 0
+ _qzz_res, 0, VG_USERREQ__INTERNAL_PRINTF_VALIST_BY_REF,
+ (unsigned long)format, (unsigned long)&vargs, 0, 0, 0
);
- va_end(args.vargs);
+ va_end(vargs);
return _qzz_res;
}
Modified: trunk/include/valgrind.h
===================================================================
--- trunk/include/valgrind.h 2010-01-27 10:28:00 UTC (rev 11031)
+++ trunk/include/valgrind.h 2010-01-28 15:23:54 UTC (rev 11032)
@@ -4122,8 +4122,17 @@
VG_USERREQ__MEMPOOL_EXISTS = 0x130a,
/* Allow printfs to valgrind log. */
+ /* The first two pass the va_list argument by value, which
+ assumes it is the same size as or smaller than a UWord,
+ which generally isn't the case. Hence are deprecated.
+ The second two pass the vargs by reference and so are
+ immune to this problem. */
+ /* both :: char* fmt, va_list vargs (DEPRECATED) */
VG_USERREQ__PRINTF = 0x1401,
VG_USERREQ__PRINTF_BACKTRACE = 0x1402,
+ /* both :: char* fmt, va_list* vargs */
+ VG_USERREQ__PRINTF_VALIST_BY_REF = 0x1403,
+ VG_USERREQ__PRINTF_BACKTRACE_VALIST_BY_REF = 0x1404,
/* Stack support. */
VG_USERREQ__STACK_REGISTER = 0x1501,
@@ -4183,16 +4192,14 @@
VALGRIND_PRINTF(const char *format, ...)
{
unsigned long _qzz_res;
- union {
- va_list vargs;
- unsigned long ul;
- } args;
- va_start(args.vargs, format);
- VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, VG_USERREQ__PRINTF,
+ va_list vargs;
+ va_start(vargs, format);
+ VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0,
+ VG_USERREQ__PRINTF_VALIST_BY_REF,
(unsigned long)format,
- (unsigned long)(args.ul),
+ (unsigned long)&vargs,
0, 0, 0);
- va_end(args.vargs);
+ va_end(vargs);
return (int)_qzz_res;
}
@@ -4202,16 +4209,14 @@
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
unsigned long _qzz_res;
- union {
- va_list vargs;
- unsigned long ul;
- } args;
- va_start(args.vargs, format);
- VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, VG_USERREQ__PRINTF_BACKTRACE,
+ va_list vargs;
+ va_start(vargs, format);
+ VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0,
+ VG_USERREQ__PRINTF_BACKTRACE_VALIST_BY_REF,
(unsigned long)format,
- (unsigned long)(args.ul),
+ (unsigned long)&vargs,
0, 0, 0);
- va_end(args.vargs);
+ va_end(vargs);
return (int)_qzz_res;
}
|
|
From: Konstantin S. <kon...@gm...> - 2010-01-28 15:17:31
|
On Thu, Jan 28, 2010 at 1:02 PM, Julian Seward <js...@ac...> wrote: > On Thursday 28 January 2010, Konstantin Serebryany wrote: > > I agree that the current annotations used to implement barrier support in > > ThreadSanitizer *may* *in theory* hide some races. > > But I would like to see an example where it really hides them. > > And then, I would like to see a *realistic* example. :) > > I see what you are saying. But overall I would much prefer to have > an annotation mechanism which can express exactly the set of inter-thread > dependencies, without adding any unnecessary ones. It may be mostly > of theoretical interest, but I think it is conceptually cleaner. From > the perspective of debugging and verifying the checkers, it's going to > be more difficult to reason about behaviour if the checkers are > dealing with a mixture of required and "fake" inter-thread dependencies. > Yeaaa. Still, I want a unit test were the current implementation hides a race. W/o a unittest, how do we test that the new implementation is correct (or at least better)? > > > I agree that AH_BEFORE_OVERWRITE and A_FORGET might be needed in some > > cases. (but again, I'd like to see a *realistic* test where the current > > annotations hide a race) > > But the problem with the annotations is that we already have too many of > > them and the users are sometimes confused. > > Maybe we should review the set to see if any are unneccessary. > There are two which are broken, I need to get rid of them. ANNOTATE_UNPUBLISH... is completely broken (bad idea) ANNOTATE_PUBLISH... is broken in case we are using literace-like sampling The rest are heavily used... > > > > Also, are we talking here about implementing barrier support inside a > tool > > (helgrind, drd, tsan, etc) or about exporting these annotations to users > so > > that they can use it for their custom barriers? > > Mostly the latter. But once we can correctly annotate custom barriers, > exactly the same annotations should be usable to annotation > pthread_barrier_* > functions. So, really, "both". > > J > |
|
From: Julian S. <js...@ac...> - 2010-01-28 09:47:51
|
On Thursday 28 January 2010, Konstantin Serebryany wrote: > I agree that the current annotations used to implement barrier support in > ThreadSanitizer *may* *in theory* hide some races. > But I would like to see an example where it really hides them. > And then, I would like to see a *realistic* example. :) I see what you are saying. But overall I would much prefer to have an annotation mechanism which can express exactly the set of inter-thread dependencies, without adding any unnecessary ones. It may be mostly of theoretical interest, but I think it is conceptually cleaner. From the perspective of debugging and verifying the checkers, it's going to be more difficult to reason about behaviour if the checkers are dealing with a mixture of required and "fake" inter-thread dependencies. > I agree that AH_BEFORE_OVERWRITE and A_FORGET might be needed in some > cases. (but again, I'd like to see a *realistic* test where the current > annotations hide a race) > But the problem with the annotations is that we already have too many of > them and the users are sometimes confused. Maybe we should review the set to see if any are unneccessary. > Also, are we talking here about implementing barrier support inside a tool > (helgrind, drd, tsan, etc) or about exporting these annotations to users so > that they can use it for their custom barriers? Mostly the latter. But once we can correctly annotate custom barriers, exactly the same annotations should be usable to annotation pthread_barrier_* functions. So, really, "both". J |
|
From: Julian S. <js...@ac...> - 2010-01-28 09:40:48
|
> By the way, the "abstract_handle" is unnecessary in my opinion. Since > B_DEPART() will always be invoked from the same thread as the > corresponding B_ARRIVE() call, a threading tool can figure out which > B_DEPART() corresponds to B_ARRIVE() call by keeping a limited amount > of state information. Yes, I think you're right. The extra information is: for each thread, the current barrier we're associated with, and, for that barrier, the VTS we must update our state by, when leaving. I think that would make the implementation more complex, though. Using the abstract_handles, the checker only needs to keep track of data per-barrier. With your "completely automatic" proposal it would have to also have some per-thread data. J |
|
From: Konstantin S. <kon...@gm...> - 2010-01-28 08:39:43
|
Hello,
It looks like the futex syscall with FUTEX_WAKE parameter is handled
incorrectly by the valgrind core.
PRE(sys_futex)
{
/*
arg param used by ops
ARG1 - u32 *futex all
...
PRE_MEM_READ( "futex(futex)", ARG1, sizeof(Int) );
When futex is called with FUTEX_WAKE, the first parameter is not
dereferenced and hence valgrind should not do PRE_MEM_READ( "futex(futex)",
ARG1, sizeof(Int) );
>From man 2 futex:
FUTEX_WAKE
This operation wakes at most val processes waiting on this
futex address (i.e., inside FUTEX_WAIT).
Here is a legal program on which memcheck complains:
int *f;
void *wait_thread(void *) {
printf("wait_thread in\n");
sys_futex(f, FUTEX_WAIT, 42, 0);
printf("wait_thread out\n");
}
int main() {
f = (int*)malloc(sizeof(int));
*f = 42;
pthread_t t;
pthread_create(&t, NULL, wait_thread, NULL);
sleep(2);
printf("calling sys_futex(f, FUTEX_WAKE, 42) (first time)\n");
sys_futex(f, FUTEX_WAKE, 42, 0);
pthread_join(t, NULL);
printf("calling free(f)\n");
free (f);
printf("calling sys_futex(f, FUTEX_WAKE, 42) (second time; f has been
already freed)\n");
sys_futex(f, FUTEX_WAKE, 42, 0);
return 0;
}
==28526== Syscall param futex(futex) points to unaddressable byte(s)
==28526== at 0x4007E6: sys_futex(int*, int, int, kernel_timespec*) (in
/home/kcc/tmp/a.out)
==28526== by 0x4008CF: main (in /home/kcc/tmp/a.out)
==28526== Address 0x5b40040 is 0 bytes inside a block of size 4 free'd
==28526== at 0x4C22D2B: free (vg_replace_malloc.c:325)
==28526== by 0x4008AA: main (in /home/kcc/tmp/a.out)
==28526==
Could someone please fix this?
Shall I open a bug report?
Thanks,
--kcc
|
|
From: Bart V. A. <bar...@gm...> - 2010-01-28 08:29:10
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-28 02:00:05 EST Ended at 2010-01-28 03:28:54 EST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 449 tests, 43 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) 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) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Konstantin S. <kon...@gm...> - 2010-01-28 07:47:28
|
I agree that the current annotations used to implement barrier support in ThreadSanitizer *may* *in theory* hide some races. But I would like to see an example where it really hides them. And then, I would like to see a *realistic* example. :) I agree that AH_BEFORE_OVERWRITE and A_FORGET might be needed in some cases. (but again, I'd like to see a *realistic* test where the current annotations hide a race) But the problem with the annotations is that we already have too many of them and the users are sometimes confused. Also, are we talking here about implementing barrier support inside a tool (helgrind, drd, tsan, etc) or about exporting these annotations to users so that they can use it for their custom barriers? One other thing. I think, for the semantics of the annotations to make sense generally, you need to say that, although the checker may run the threads concurrently, it must process each annotation atomically. It sounds like hair splitting, I know, but .. it's hard to see what the effect would be if processing of annotations was allowed to happen concurrently. good point :) --kcc On Thu, Jan 28, 2010 at 10:32 AM, Bart Van Assche <bva...@ac...>wrote: > On Wed, Jan 27, 2010 at 6:09 PM, Julian Seward <js...@ac...> wrote: > > > > [ ... ] > > > > IOW we need to deal in the worst case with an arbitrary delay between > > a thread leaving the barrier proper and having its state updated at > > the B_DEPART request. > > > > Hence I am now thinking instead of the following annotations: > > > > B_INITIALISE(bar, int capacity) > > initialise; state capacity > > > > void* abstract_handle = B_ARRIVE(bar) > > arrive at barrier. obtain abstract handle (a VTS*, essentially) > from > > which we need to update when leaving > > > > B_DEPART(bar, abstract_handle) > > depart from barrier, updating our VTS using the one we were given > > by B_ARRIVE > > The above looks a lot better to me than instrumenting user-implemented > barriers via AH_BEFORE() and AH_AFTER(). While the latter approach is > sufficient for suppressing false positives triggered by a user barrier > implementation, these is a high risk that instrumenting > user-implemented barriers via AH_BEFORE() and AH_AFTER() will suppress > real races because these primitives introduce more inter-thread > ordering than barriers. The above proposal doesn't have that > disadvantage. > > By the way, the "abstract_handle" is unnecessary in my opinion. Since > B_DEPART() will always be invoked from the same thread as the > corresponding B_ARRIVE() call, a threading tool can figure out which > B_DEPART() corresponds to B_ARRIVE() call by keeping a limited amount > of state information. > > Bart. > |
|
From: Konstantin S. <kon...@gm...> - 2010-01-28 07:37:30
|
Sent a log off list With logging on it does not really want to hang. Instead (with ~5% probability) it loops forever. I think this is the same bug -- the process misses its own death time... --kcc On Thu, Jan 28, 2010 at 10:40 AM, Julian Seward <js...@ac...> wrote: > On Wednesday 27 January 2010, Julian Seward wrote: > > On Wednesday 27 January 2010, Konstantin Serebryany wrote: > > > I've minimized the problem to a small test (below). > > > It spawns many threads and doesn't join them before exiting. > > > It will hang (or loop forever) one out of 40-100 runs: > > > % g++ -g -lpthread hang.cc > > > % for((i=10;i<=99;i++)); do date; time > ~/valgrind/trunk/inst/bin/valgrind > > > --tool=none --trace-syscalls=yes --trace-signals=yes -q ./a.out 2> > > > $i.log ; done > > > > Ok; managed to reproduce it. 2 threads were still stuck in some syscall > > (don't know which yet). Investigating. > > I can reproduce it, but only in the case where there is no logging, > which isn't useful. If you have a logfile where it hangs for > --trace-syscalls=yes --trace-signals=yes, can you compress it and > send it to me? afaics the log is about 40MB long, but it should > bzip2 nicely. > > J > |
|
From: Bart V. A. <bva...@ac...> - 2010-01-28 07:32:49
|
On Wed, Jan 27, 2010 at 6:09 PM, Julian Seward <js...@ac...> wrote: > > [ ... ] > > IOW we need to deal in the worst case with an arbitrary delay between > a thread leaving the barrier proper and having its state updated at > the B_DEPART request. > > Hence I am now thinking instead of the following annotations: > > B_INITIALISE(bar, int capacity) > initialise; state capacity > > void* abstract_handle = B_ARRIVE(bar) > arrive at barrier. obtain abstract handle (a VTS*, essentially) from > which we need to update when leaving > > B_DEPART(bar, abstract_handle) > depart from barrier, updating our VTS using the one we were given > by B_ARRIVE The above looks a lot better to me than instrumenting user-implemented barriers via AH_BEFORE() and AH_AFTER(). While the latter approach is sufficient for suppressing false positives triggered by a user barrier implementation, these is a high risk that instrumenting user-implemented barriers via AH_BEFORE() and AH_AFTER() will suppress real races because these primitives introduce more inter-thread ordering than barriers. The above proposal doesn't have that disadvantage. By the way, the "abstract_handle" is unnecessary in my opinion. Since B_DEPART() will always be invoked from the same thread as the corresponding B_ARRIVE() call, a threading tool can figure out which B_DEPART() corresponds to B_ARRIVE() call by keeping a limited amount of state information. Bart. |
|
From: Julian S. <js...@ac...> - 2010-01-28 07:26:33
|
On Wednesday 27 January 2010, Julian Seward wrote: > On Wednesday 27 January 2010, Konstantin Serebryany wrote: > > I've minimized the problem to a small test (below). > > It spawns many threads and doesn't join them before exiting. > > It will hang (or loop forever) one out of 40-100 runs: > > % g++ -g -lpthread hang.cc > > % for((i=10;i<=99;i++)); do date; time ~/valgrind/trunk/inst/bin/valgrind > > --tool=none --trace-syscalls=yes --trace-signals=yes -q ./a.out 2> > > $i.log ; done > > Ok; managed to reproduce it. 2 threads were still stuck in some syscall > (don't know which yet). Investigating. I can reproduce it, but only in the case where there is no logging, which isn't useful. If you have a logfile where it hangs for --trace-syscalls=yes --trace-signals=yes, can you compress it and send it to me? afaics the log is about 40MB long, but it should bzip2 nicely. J |
|
From: Alexander P. <gl...@go...> - 2010-01-28 06:43:14
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2010-01-28 09:06:01 MSK Ended at 2010-01-28 09:30:39 MSK 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 == 433 tests, 22 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) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-01-28 03:49:27
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-28 03:05:04 GMT Ended at 2010-01-28 03:49:09 GMT 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 == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-01-28 03:36:16
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-28 03:10:05 GMT Ended at 2010-01-28 03:36:02 GMT 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 == 538 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 == 538 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 Thu Jan 28 03:22:59 2010 --- new.short Thu Jan 28 03:36:02 2010 *************** *** 8,10 **** ! == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) --- 8,11 ---- ! == 538 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) |