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: Julian S. <js...@ac...> - 2010-01-27 17:14:41
|
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. J |
|
From: Julian S. <js...@ac...> - 2010-01-27 16:54:54
|
> Also, I'd like to propose new annotations for barriers. We can annotate
> barriers in terms of the above 4, but that hardwires the assumption that
> the underlying checker has a concept of h-b edges. I'd prefer a set
> of macros which merely specify the state of the barrier:
>
> B_RESET(bar)
> state that nobody is waiting for the barrier
>
> B_ARRIVE(bar)
> i have arrived at the barrier
>
> B_DEPART(bar, Bool i_am_the_last_to_depart)
> i have left the barrier, and give an indication of whether or
> not I am the last to leave. (If so, the checker would
> probably want to behave like B_RESET).
Actually, even with those, I think it is impossible to guarantee a correct
annotation in the worst-case race condition. In the worst-case condition
we need an arbitrary number of VTSs associated with the barrier, and also
to track how many threads are waiting at the barrier.
This is because it could be that threads leaving the "real" barrier
call/mechanism stall and do not get to the B_DEPART request (at which
point their VTSs are updated) before a whole different set of threads arrive
at the barrier, pass through it, add their own set of edges to it. Then
the original threads finally get to their B_DEPART requests, at which
point they get the edges of these "overtaking" threads incorrectly
added.
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
---------------------
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.
J
|
|
From: Julian S. <js...@ac...> - 2010-01-27 16:24:10
|
Konstantin, I'm trying to annotate a user-implemented barrier, using http://code.google.com/p/google-perftools/source/browse/trunk/src/base/dynamic_annotations.h specifically ANNOTATE_HAPPENS_BEFORE and ANNOTATE_HAPPENS_AFTER like this void barrier_wait ( barrier* b ) { ANNOTATE_HAPPENS_BEFORE(b); // the barrier implementation ANNOTATE_HAPPENS_AFTER(b); } But this doesn't work well, and I think it's not clear what semantics you intended for these two. This situation I can understand: T1: AH_BEFORE(obj) T2: AH_AFTER(obj) then we get an edge T1->T2 But what about this? T1: AH_BEFORE(obj) T2: AH_BEFORE(obj) T3: AH_AFTER(obj) Should we get edges T1->T3 and T2->T3, or only T2->T3 ? IOW, does a call AH_BEFORE(obj) cause obj to "forget" about any previous AH_BEFORE calls on it? It seems to me that to annotate a barrier properly requires generating two edges in this example, not just one. (Plus then it requires a way to tell obj to "forget everything" when the barrier is reinitialised, so that subsequent uses of it do not end up generating edges back to previous uses.) J |
|
From: Julian S. <js...@ac...> - 2010-01-27 16:24:07
|
> > But this doesn't work well, and I think it's not clear what semantics
> > you intended for these two.
> >
> > This situation I can understand:
> >
> > T1: AH_BEFORE(obj)
> > T2: AH_AFTER(obj)
> >
> > then we get an edge T1->T2
> >
> > But what about this?
> >
> > T1: AH_BEFORE(obj)
> > T2: AH_BEFORE(obj)
> > T3: AH_AFTER(obj)
> >
> > Should we get edges T1->T3 and T2->T3,
>
> Yes, we will get two edges.
> The h-before events are never forgotten. (ThreadSanitizer forgets them when
> it flushes the entire state)
I don't think it is good that the behaviour AH_BEFORE is hardwired
in this way. It makes the annotation set inflexible. What do you
think of the following proposal?
AH_BEFORE_OVERWRITE(obj)
forget everything in obj, then acquire a h-b dep from caller
AH_BEFORE_ACCUMULATE(obj)
merge in a h-b dep from caller; don't forget history
so your AH_BEFORE == AH_BEFORE_ACCUMULATE
AH_AFTER(obj)
acquire h-b edges from obj (unchanged)
A_FORGET(obj)
forget everything
You may not find A_FORGET and AH_BEFORE_OVERWRITE useful, but at least
there presence (+ clarification of the semantics) makes it more
flexible and controllable.
Also, I'd like to propose new annotations for barriers. We can annotate
barriers in terms of the above 4, but that hardwires the assumption that
the underlying checker has a concept of h-b edges. I'd prefer a set
of macros which merely specify the state of the barrier:
B_RESET(bar)
state that nobody is waiting for the barrier
B_ARRIVE(bar)
i have arrived at the barrier
B_DEPART(bar, Bool i_am_the_last_to_depart)
i have left the barrier, and give an indication of whether or
not I am the last to leave. (If so, the checker would
probably want to behave like B_RESET).
J
|
|
From: Julian S. <js...@ac...> - 2010-01-27 16:24:06
|
Uh, this unfortunately kills the VALGRIND_PRINTF_BACKTRACE macro
at least on amd64-linux, and, I suspect, on all platforms (V segfaults).
Problem is this
union {
va_list vargs;
unsigned long t;
} args;
va_start(args.vargs, format);
VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, VG_USERREQ__PRINTF,
(unsigned long)format, (unsigned long)(args.t),
0, 0, 0);
on amd64-linux, sizeof(vargs) == 24. So what this code does is
to initialise a 24-byte structure, pass the first 8 bytes of it
to the client request ("unsigned long)(args.t)"). Back on the
"other side of the fence", the client request handler does this
union {
va_list vargs;
unsigned long t;
} args;
Int count;
args.t = (unsigned long)arg[2];
count =
VG_(vmessage)( Vg_ClientMsg, (char *)arg[1], args.vargs );
that is, initialises the first 1/3 of the 24-byte structure with supplied
8 bytes, passes the whole structure to VG_(vmessage), and segfaults.
We can only pass machine words as arguments in client requests. So the
obvious solution is to pass a reference to the vargs structure rather
than (trying to pass) the structure itself.
This is all somewhat complicated by the fact that VG_USERREQ__PRINTF
effectively constitutes a public API, and we can't change the behaviour
of it. So there needs to be a new VG_USERREQ__PRINTF_VARGS_BY_REF request
and the VALGRIND_PRINTF_BACKTRACE (et al) macros should then use that.
J
On Monday 04 January 2010, Julian Seward wrote:
> Committed as r11006. Thanks.
>
> J
>
> On Wednesday 23 December 2009, Dmitry Zhurikhin wrote:
> > Hello.
> >
> > It seems like ARM branch can't be compiled with recent versions of GCC
> > (stock GCC 4.4 and CodeSourcery arm-2008q3 or even earlier). A patch is
> > attached that allows building of Valgrind. Probably the reason for the
> > failure is in the GCC version 4.4 changelog: "On ARM EABI targets, the
> > C++ mangling of the va_list type has been changed to conform to the
> > current revision of the EABI". This should mean that for ARM va_list is
> > not integer (but a structure it seems) anymore which is still true for
> > other platforms that Valgrind supports. Valgrind sources are written in
> > such a way that it wants va_list to be able to be casted to an integer
> > type implicitly. This is no longer available in current GCC for ARM.
> > Seems like CodeSourcery made this change a little bit earlier (as
> > original GCC version 4.3.2 is able to build Valgrind without errors).
> > Please review the patch. It only makes a cast using union.
> >
> > Following is the error log:
> > In file included from m_debuglog.c:57:
> > ../include/valgrind.h: In function 'VALGRIND_PRINTF':
> > ../include/valgrind.h:4186: error: aggregate value used where an integer
> > was expected
> > ../include/valgrind.h: In function 'VALGRIND_PRINTF_BACKTRACE':
> > ../include/valgrind.h:4201: error: aggregate value used where an integer
> > was expected
> > make[3]: *** [libcoregrind_arm_linux_a-m_debuglog.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > mv -f .deps/libcoregrind_arm_linux_a-m_debugger.Tpo
> > .deps/libcoregrind_arm_linux_a-m_debugger.Po
> > mv -f .deps/libcoregrind_arm_linux_a-m_commandline.Tpo
> > .deps/libcoregrind_arm_linux_a-m_commandline.Po
> > make[3]: Leaving directory
> > `/home/batuzovk/valgrind/valgrind-clean/coregrind' make[2]: *** [all]
> > Error 2
> > make[2]: Leaving directory
> > `/home/batuzovk/valgrind/valgrind-clean/coregrind' make[1]: ***
> > [all-recursive] Error 1
> > make[1]: Leaving directory `/home/batuzovk/valgrind/valgrind-clean'
> > make: *** [all] Error 2
> >
> >
> > Regards,
> > Dmitry
>
> ---------------------------------------------------------------------------
>--- This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Konstantin S. <kon...@gm...> - 2010-01-27 14:17:55
|
On Wed, Jan 27, 2010 at 3:41 PM, Julian Seward <js...@ac...> wrote: > > Konstantin, > > I'm trying to annotate a user-implemented barrier, using > > > http://code.google.com/p/google-perftools/source/browse/trunk/src/base/dynamic_annotations.h > specifically ANNOTATE_HAPPENS_BEFORE and ANNOTATE_HAPPENS_AFTER > > like this > > void barrier_wait ( barrier* b ) > { > ANNOTATE_HAPPENS_BEFORE(b); > // the barrier implementation > ANNOTATE_HAPPENS_AFTER(b); > } > this is exactly how I handle barrier. > > But this doesn't work well, and I think it's not clear what semantics > you intended for these two. > > This situation I can understand: > > T1: AH_BEFORE(obj) > T2: AH_AFTER(obj) > > then we get an edge T1->T2 > > But what about this? > > T1: AH_BEFORE(obj) > T2: AH_BEFORE(obj) > T3: AH_AFTER(obj) > > Should we get edges T1->T3 and T2->T3, Yes, we will get two edges. The h-before events are never forgotten. (ThreadSanitizer forgets them when it flushes the entire state) > or only T2->T3 ? IOW, does > a call AH_BEFORE(obj) cause obj to "forget" about any previous > AH_BEFORE calls on it? > > It seems to me that to annotate a barrier properly requires generating > two edges in this example, not just one. (Plus then it requires > a way to tell obj to "forget everything" when the barrier is reinitialised, > so that subsequent uses of it do not end up generating edges back to > previous uses.) > That would be possible by adding yet another annotation (ANNOTATE_FORGET_HB_EDGES(obj)) but I never found this really useful, at least in ThreadSanitizer. --kcc > > J > |
|
From: <sv...@va...> - 2010-01-27 10:28:10
|
Author: sewardj
Date: 2010-01-27 10:28:00 +0000 (Wed, 27 Jan 2010)
New Revision: 11031
Log:
Fix handling of mprotect so as to be more consistent with the handling
of mmap. Fixes #205541 and its dup #210268. The fix is simple enough
but the analysis is a bit complex, as detailed in comments.
Modified:
trunk/memcheck/mc_main.c
Modified: trunk/memcheck/mc_main.c
===================================================================
--- trunk/memcheck/mc_main.c 2010-01-26 13:26:41 UTC (rev 11030)
+++ trunk/memcheck/mc_main.c 2010-01-27 10:28:00 UTC (rev 11031)
@@ -1636,6 +1636,22 @@
}
}
+/* Similarly (needed for mprotect handling ..) */
+static void make_mem_defined_if_noaccess ( Addr a, SizeT len )
+{
+ SizeT i;
+ UChar vabits2;
+ DEBUG("make_mem_defined_if_noaccess(%p, %llu)\n", a, (ULong)len);
+ for (i = 0; i < len; i++) {
+ vabits2 = get_vabits2( a+i );
+ if (LIKELY(VA_BITS2_NOACCESS == vabits2)) {
+ set_vabits2(a+i, VA_BITS2_DEFINED);
+ if (UNLIKELY(MC_(clo_mc_level) >= 3)) {
+ MC_(helperc_b_store1)( a+i, 0 ); /* clear the origin tag */
+ }
+ }
+ }
+}
/* --- Block-copy permissions (needed for implementing realloc() and
sys_mremap). --- */
@@ -3701,17 +3717,87 @@
}
}
+/* Handling of mmap and mprotect is not as simple as it seems.
+
+ The underlying semantics are that memory obtained from mmap is
+ always initialised, but may be inaccessible. And changes to the
+ protection of memory do not change its contents and hence not its
+ definedness state. Problem is we can't model
+ inaccessible-but-with-some-definedness state; once we mark memory
+ as inaccessible we lose all info about definedness, and so can't
+ restore that if it is later made accessible again.
+
+ One obvious thing to do is this:
+
+ mmap/mprotect NONE -> noaccess
+ mmap/mprotect other -> defined
+
+ The problem case here is: taking accessible memory, writing
+ uninitialised data to it, mprotecting it NONE and later mprotecting
+ it back to some accessible state causes the undefinedness to be
+ lost.
+
+ A better proposal is:
+
+ (1) mmap NONE -> make noaccess
+ (2) mmap other -> make defined
+
+ (3) mprotect NONE -> # no change
+ (4) mprotect other -> change any "noaccess" to "defined"
+
+ (2) is OK because memory newly obtained from mmap really is defined
+ (zeroed out by the kernel -- doing anything else would
+ constitute a massive security hole.)
+
+ (1) is OK because the only way to make the memory usable is via
+ (4), in which case we also wind up correctly marking it all as
+ defined.
+
+ (3) is the weak case. We choose not to change memory state.
+ (presumably the range is in some mixture of "defined" and
+ "undefined", viz, accessible but with arbitrary V bits). Doing
+ nothing means we retain the V bits, so that if the memory is
+ later mprotected "other", the V bits remain unchanged, so there
+ can be no false negatives. The bad effect is that if there's
+ an access in the area, then MC cannot warn; but at least we'll
+ get a SEGV to show, so it's better than nothing.
+
+ Consider the sequence (3) followed by (4). Any memory that was
+ "defined" or "undefined" previously retains its state (as
+ required). Any memory that was "noaccess" before can only have
+ been made that way by (1), and so it's OK to change it to
+ "defined".
+
+ See https://bugs.kde.org/show_bug.cgi?id=205541
+ and https://bugs.kde.org/show_bug.cgi?id=210268
+*/
static
void mc_new_mem_mmap ( Addr a, SizeT len, Bool rr, Bool ww, Bool xx,
ULong di_handle )
{
- if (rr || ww || xx)
+ if (rr || ww || xx) {
+ /* (2) mmap/mprotect other -> defined */
MC_(make_mem_defined)(a, len);
- else
+ } else {
+ /* (1) mmap/mprotect NONE -> noaccess */
MC_(make_mem_noaccess)(a, len);
+ }
}
static
+void mc_new_mem_mprotect ( Addr a, SizeT len, Bool rr, Bool ww, Bool xx )
+{
+ if (rr || ww || xx) {
+ /* (4) mprotect other -> change any "noaccess" to "defined" */
+ make_mem_defined_if_noaccess(a, len);
+ } else {
+ /* (3) mprotect NONE -> # no change */
+ /* do nothing */
+ }
+}
+
+
+static
void mc_new_mem_startup( Addr a, SizeT len,
Bool rr, Bool ww, Bool xx, ULong di_handle )
{
@@ -5780,7 +5866,7 @@
//
// So we should arguably observe all this. However:
// - The current inaccuracy has caused maybe one complaint in seven years(?)
- // - Telying on the zeroed-ness of whole brk'd pages is pretty grotty... I
+ // - Relying on the zeroed-ness of whole brk'd pages is pretty grotty... I
// doubt most programmers know the above information.
// So I'm not terribly unhappy with marking it as undefined. --njn.
//
@@ -5790,21 +5876,15 @@
// just mark all memory it allocates as defined.]
//
VG_(track_new_mem_brk) ( make_mem_undefined_w_tid );
+
+ // Handling of mmap and mprotect isn't simple (well, it is simple,
+ // but the justification isn't.) See comments above, just prior to
+ // mc_new_mem_mmap.
VG_(track_new_mem_mmap) ( mc_new_mem_mmap );
+ VG_(track_change_mem_mprotect) ( mc_new_mem_mprotect );
VG_(track_copy_mem_remap) ( MC_(copy_address_range_state) );
- // Nb: we don't do anything with mprotect. This means that V bits are
- // preserved if a program, for example, marks some memory as inaccessible
- // and then later marks it as accessible again.
- //
- // If an access violation occurs (eg. writing to read-only memory) we let
- // it fault and print an informative termination message. This doesn't
- // happen if the program catches the signal, though, which is bad. If we
- // had two A bits (for readability and writability) that were completely
- // distinct from V bits, then we could handle all this properly.
- VG_(track_change_mem_mprotect) ( NULL );
-
VG_(track_die_mem_stack_signal)( MC_(make_mem_noaccess) );
VG_(track_die_mem_brk) ( MC_(make_mem_noaccess) );
VG_(track_die_mem_munmap) ( MC_(make_mem_noaccess) );
|
|
From: Konstantin S. <kon...@gm...> - 2010-01-27 09:47:29
|
On Wed, Jan 27, 2010 at 12:59 PM, Julian Seward <js...@ac...> wrote: > On Wednesday 27 January 2010, Konstantin Serebryany wrote: > > I've minimized the problem to a small test (below). > > Good that there's a small test case now. > > So .. this is on which platform? something-linux, or something-darwin? > I am seeing it on x86_64 linux (ubuntu 8.04) w/o the --trace-... flags it hangs more often: for((i=10;i<=99;i++)); do date; time ~/valgrind/trunk/inst/bin/valgrind --tool=none -q ./a.out 2> $i.log ; done > > J > |
|
From: Julian S. <js...@ac...> - 2010-01-27 09:44:51
|
On Wednesday 27 January 2010, Konstantin Serebryany wrote: > I've minimized the problem to a small test (below). Good that there's a small test case now. So .. this is on which platform? something-linux, or something-darwin? J |
|
From: Konstantin S. <kon...@gm...> - 2010-01-27 09:37:43
|
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
Even nulgrind is affected.
Any suggestion?
Thanks,
--kcc
--------------------------------------------------------------------------------------------------------
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
void *run(void *p) {
for (int i = 0; ; i++) {
usleep(100);
fprintf(stderr, "T=%d i=%d\n", (int)pthread_self(), i);
}
return NULL;
}
int main(int argc, char** argv) {
for (int i = 0; i < 200; i++) {
pthread_t t;
pthread_create(&t, NULL, run, NULL);
}
fprintf(stderr, "exiting main\n");
return 0;
}
--------------------------------------------------------------------------------------------------------
On Mon, Jan 18, 2010 at 12:56 PM, Julian Seward <js...@ac...> wrote:
> On Monday 18 January 2010, Konstantin Serebryany wrote:
> > On Wed, Jan 13, 2010 at 4:54 PM, Julian Seward <js...@ac...> wrote:
> > > > Any idea how to attack the problem?
> > > > Any workaround?
> > >
> > > Don't know, sorry. Obviously if you can reduce it to a test case
> > > that is small enough to be debuggable
> >
> > trying...
> >
> > When strace-ing an already hung process, I see this line:
> > read(32761, <unfinished ...>
> >
> > Does it tell you anything?
> > Does 32761 look like a legitimate fd?
>
> Hmm, I don't know. I don't think it's legit but am not sure.
>
> J
>
> >
> > --kcc
> >
> > > , that would be a big help.
> > >
> > > J
>
>
>
|
|
From: Bart V. A. <bar...@gm...> - 2010-01-27 09:04:01
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-27 02:34:32 EST Ended at 2010-01-27 04:03:42 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: Bart V. A. <bar...@gm...> - 2010-01-27 07:28:01
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-27 02:27:50 EST Ended at 2010-01-27 02:27:54 EST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-27T02:27:50} valgrind-new conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Configuring valgrind ... cd valgrind-new && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-new/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Building valgrind ... cd valgrind-new && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Running regression tests ... cd valgrind-new && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-26T02:27:50} valgrind-old conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Configuring valgrind ... cd valgrind-old && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-old/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Building valgrind ... cd valgrind-old && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory Running regression tests ... cd valgrind-old && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found Job ID = cat: cmd-output.txt: No such file or directory ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Jan 27 02:27:54 2010 --- new.short Wed Jan 27 02:27:54 2010 *************** *** 8,10 **** ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-26T02:27:50} valgrind-old conf/cellbuzz-native.conf: line 16: qsub: command not found --- 8,10 ---- ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-27T02:27:50} valgrind-new conf/cellbuzz-native.conf: line 16: qsub: command not found *************** *** 12,14 **** cat: cmd-output.txt: No such file or directory ! Configuring valgrind ... cd valgrind-old && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-old/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found --- 12,14 ---- cat: cmd-output.txt: No such file or directory ! Configuring valgrind ... cd valgrind-new && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-new/Inst conf/cellbuzz-native.conf: line 16: qsub: command not found *************** *** 16,18 **** cat: cmd-output.txt: No such file or directory ! Building valgrind ... cd valgrind-old && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found --- 16,18 ---- cat: cmd-output.txt: No such file or directory ! Building valgrind ... cd valgrind-new && make -j 2 && make -j 2 check && make install conf/cellbuzz-native.conf: line 16: qsub: command not found *************** *** 20,22 **** cat: cmd-output.txt: No such file or directory ! Running regression tests ... cd valgrind-old && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found --- 20,22 ---- cat: cmd-output.txt: No such file or directory ! Running regression tests ... cd valgrind-new && make regtest conf/cellbuzz-native.conf: line 16: qsub: command not found |
|
From: Alexander P. <gl...@go...> - 2010-01-27 06:51:58
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2010-01-27 09:06:02 MSK Ended at 2010-01-27 09:29:26 MSK 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 == 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) ================================================= == 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 == 433 tests, 22 stderr failures, 2 stdout failures, 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) drd/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Jan 27 09:18:31 2010 --- new.short Wed Jan 27 09:29:26 2010 *************** *** 8,10 **** ! == 433 tests, 22 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/null_socket (stdout) --- 8,10 ---- ! == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) *************** *** 32,34 **** helgrind/tests/tc23_bogus_condwait (stderr) - drd/tests/pth_detached (stdout) --- 32,33 ---- -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2010-01-27 03:49:50
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-27 03:05:04 GMT Ended at 2010-01-27 03:49:32 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-27 03:35:54
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-27 03:10:06 GMT Ended at 2010-01-27 03:35:41 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, 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 == 538 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 Wed Jan 27 03:22:59 2010 --- new.short Wed Jan 27 03:35:41 2010 *************** *** 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) --- 8,10 ---- ! == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |