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
(6) |
2
(3) |
3
|
4
(3) |
5
(10) |
6
(4) |
7
(5) |
|
8
(1) |
9
(3) |
10
(11) |
11
(18) |
12
(13) |
13
(4) |
14
(11) |
|
15
(12) |
16
(6) |
17
(1) |
18
(13) |
19
(14) |
20
(12) |
21
(3) |
|
22
(17) |
23
(18) |
24
(17) |
25
(24) |
26
(15) |
27
(7) |
28
(23) |
|
29
(31) |
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 23:04:47
|
On Sat, 14 Feb 2004, Tom Hughes wrote: > > AIUI, the fdsets are bit arrays, with 1024 bits, each bit representing an > > fd; if bit N is set in an array, select will watch fd N appropriately. > > The first arg, n, is the highest N for which a bit is set, plus one. > > Therefore, select() will read at least n bits in each array. Thus, the > > a1/8 is close, but not quite right; it's not rounding up to allow for any > > unused bits at the end of the read bytes. For example, most of the time n > > will be less than 8, in which case the length passed to pre_mem_read will > > be zero! I think it needs to be (a1+7)/8. > > The problem with rounding up instead of down is that it may cause > false positives because there is no guarantee that all the bits in > the final byte will be defined - if I pass 3 as the first argument > that I only have to fill in the first three bits of the first byte > and the others may be undefined as the kernel won't pay any attention > to them. > > The problem is that although valgrind tracks definedness at the bit > level the interface that the syscall stuff uses to check it only works > at byte granularity. Right, I hadn't thought of that. However, I'm still in favour of rounding up. In general, what does pre_mem_read indicate -- bytes that are read, or bytes that are used? I favour the former. It seems to me the right approach is to smarten Memcheck to be aware of this case. Failing that, being conservative and saying the whole byte is read seems better to me, since I'd rather a false positive than a false negative. N |
|
From: Doug R. <df...@nl...> - 2004-02-14 19:18:06
|
On Sat, 2004-02-14 at 18:45, Jeremy Fitzhardinge wrote: > On Sat, 2004-02-14 at 09:23, Doug Rabson wrote: > > I've been trying to sort out a problem found by one of the people > > testing the FreeBSD valgrind and it looks like a nice tricky one. They > > have one thread which blocks itself in pthread_cond_wait. Thats the > > first problem, valgrind immediately dies thinking there is a deadlock. I > > can 'fix' that by not panicing if all threads are stuck waiting on CVs. > > > > The next part of the test isn't so easy. The user issues a SIGINT (via > > ^C or similar) which is caught by a signal handler which calls > > pthread_cond_broadcast. This is supposed to allow the program to exit. > > Unfortunately, the broadcast is ignored because while the thread is in > > the signal handler it isn't in WaitCV state. > > > > Anyway, the testcase is attached for your amusement. > > I was wondering when people would try something insane like this. The > deadlock test isn't completely correct, because as you say, most > blocking functions can be interrupted by a signal (though is it OK to > use pthread_cond_broadcast in a signal handler?). > > >From the scheduler's perspective, it's hard to see how you can come up > with a sane notion of being both blocked in a CV and actually executing > instructions at the same time... Still, this behaviour works 'correctly' on FreeBSD, Linux, Solaris and probably most other pthreads implementations. This testcase is a distillation of how they get their application to shutdown cleanly. The main problem is that while it runs the signal handler, the thread isn't in WaitCV state (so the pthread_cond_broadcast doesn't do anything) but when the signal frame is popped, it goes right back to sleep. Somehow I need to be able to tweak the saved thread state in the signal frame (or something). |
|
From: Jeremy F. <je...@go...> - 2004-02-14 18:47:54
|
On Sat, 2004-02-14 at 09:23, Doug Rabson wrote: > I've been trying to sort out a problem found by one of the people > testing the FreeBSD valgrind and it looks like a nice tricky one. They > have one thread which blocks itself in pthread_cond_wait. Thats the > first problem, valgrind immediately dies thinking there is a deadlock. I > can 'fix' that by not panicing if all threads are stuck waiting on CVs. > > The next part of the test isn't so easy. The user issues a SIGINT (via > ^C or similar) which is caught by a signal handler which calls > pthread_cond_broadcast. This is supposed to allow the program to exit. > Unfortunately, the broadcast is ignored because while the thread is in > the signal handler it isn't in WaitCV state. > > Anyway, the testcase is attached for your amusement. I was wondering when people would try something insane like this. The deadlock test isn't completely correct, because as you say, most blocking functions can be interrupted by a signal (though is it OK to use pthread_cond_broadcast in a signal handler?). >From the scheduler's perspective, it's hard to see how you can come up with a sane notion of being both blocked in a CV and actually executing instructions at the same time... J |
|
From: Doug R. <df...@nl...> - 2004-02-14 17:26:28
|
I've been trying to sort out a problem found by one of the people testing the FreeBSD valgrind and it looks like a nice tricky one. They have one thread which blocks itself in pthread_cond_wait. Thats the first problem, valgrind immediately dies thinking there is a deadlock. I can 'fix' that by not panicing if all threads are stuck waiting on CVs. The next part of the test isn't so easy. The user issues a SIGINT (via ^C or similar) which is caught by a signal handler which calls pthread_cond_broadcast. This is supposed to allow the program to exit. Unfortunately, the broadcast is ignored because while the thread is in the signal handler it isn't in WaitCV state. Anyway, the testcase is attached for your amusement. |
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 16:56:30
|
CVS commit by nethercote:
Remove compile warnings.
M +2 -0 gen_insn_test.pl 1.3
--- valgrind/none/tests/gen_insn_test.pl #1.2:1.3
@@ -135,4 +135,5 @@
}
+__attribute__((unused))
static int eq_float(float f1, float f2)
{
@@ -140,4 +141,5 @@
}
+__attribute__((unused))
static int eq_double(double d1, double d2)
{
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 16:51:11
|
CVS commit by nethercote: Whoops, meant to add with Massif. A filter_stderr 1.1 |
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 16:48:58
|
CVS commit by nethercote: Whoops, meant to add this with the rest of Massif. A Makefile.am 1.1 |
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 16:42:41
|
CVS commit by nethercote:
Adding Massif, the heap profiler.
A massif/Makefile.am 1.1
A massif/ms_main.c 1.1 [GPL (v2+)]
A massif/docs/Makefile.am 1.1
A massif/docs/date.gif 1.1
A massif/docs/ms_main.html 1.1
A massif/hp2ps/AreaBelow.c 1.1 [no copyright]
A massif/hp2ps/AreaBelow.h 1.1 [no copyright]
A massif/hp2ps/AuxFile.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/AuxFile.h 1.1 [no copyright]
A massif/hp2ps/Axes.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Axes.h 1.1 [no copyright]
A massif/hp2ps/CHANGES 1.1
A massif/hp2ps/Curves.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Curves.h 1.1 [no copyright]
A massif/hp2ps/Defines.h 1.1 [no copyright]
A massif/hp2ps/Deviation.c 1.1 [no copyright]
A massif/hp2ps/Deviation.h 1.1 [no copyright]
A massif/hp2ps/Dimensions.c 1.1 [no copyright]
A massif/hp2ps/Dimensions.h 1.1 [no copyright]
A massif/hp2ps/Error.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Error.h 1.1 [no copyright]
A massif/hp2ps/HpFile.c 1.1 [no copyright]
A massif/hp2ps/HpFile.h 1.1 [no copyright]
A massif/hp2ps/INSTALL 1.1
A massif/hp2ps/Key.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Key.h 1.1 [no copyright]
A massif/hp2ps/LICENSE 1.1
A massif/hp2ps/Main.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Main.h 1.1 [no copyright]
A massif/hp2ps/Marks.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Marks.h 1.1 [no copyright]
A massif/hp2ps/PsFile.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/PsFile.h 1.1 [no copyright]
A massif/hp2ps/README 1.1
A massif/hp2ps/Reorder.c 1.1 [no copyright]
A massif/hp2ps/Reorder.h 1.1 [no copyright]
A massif/hp2ps/Scale.c 1.1 [no copyright]
A massif/hp2ps/Scale.h 1.1 [no copyright]
A massif/hp2ps/Shade.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Shade.h 1.1 [no copyright]
A massif/hp2ps/TopTwenty.c 1.1 [no copyright]
A massif/hp2ps/TopTwenty.h 1.1 [no copyright]
A massif/hp2ps/TraceElement.c 1.1 [no copyright]
A massif/hp2ps/TraceElement.h 1.1 [no copyright]
A massif/hp2ps/Utilities.c 1.1 [POSSIBLY UNSAFE: printf] [no copyright]
A massif/hp2ps/Utilities.h 1.1 [no copyright]
A massif/hp2ps/hp2ps.1 1.1
A massif/tests/Makefile.am 1.1
A massif/tests/true_html.stderr.exp 1.1
A massif/tests/true_html.vgtest 1.1
A massif/tests/true_text.stderr.exp 1.1
A massif/tests/true_text.vgtest 1.1
M +1 -0 Makefile.am 1.63
M +7 -3 configure.in 1.105
M +0 -3 coregrind/vg_include.h 1.181
M +6 -3 docs/manual.html 1.48
M +4 -0 include/vg_skin.h.base 1.13
--- valgrind/Makefile.am #1.62:1.63
@@ -10,4 +10,5 @@
corecheck \
helgrind \
+ massif \
lackey \
none
--- valgrind/configure.in #1.104:1.105
@@ -374,10 +374,14 @@
cachegrind/docs/Makefile
cachegrind/cg_annotate
- corecheck/Makefile
- corecheck/tests/Makefile
- corecheck/docs/Makefile
helgrind/Makefile
helgrind/tests/Makefile
helgrind/docs/Makefile
+ massif/Makefile
+ massif/hp2ps/Makefile
+ massif/tests/Makefile
+ massif/docs/Makefile
+ corecheck/Makefile
+ corecheck/tests/Makefile
+ corecheck/docs/Makefile
lackey/Makefile
lackey/tests/Makefile
--- valgrind/coregrind/vg_include.h #1.180:1.181
@@ -1366,7 +1366,4 @@ extern Int VG_(vgexecfd);
extern Int VG_(clexecfd);
-/* Path to all our library/aux files */
-extern const Char *VG_(libdir);
-
/* Determine if %esp adjustment must be noted */
extern Bool VG_(need_to_handle_esp_assignment) ( void );
--- valgrind/docs/manual.html #1.47:1.48
@@ -99,4 +99,7 @@
Helgrind: a data-race detector</a></h4>
+<h4>7 <a href="ms_main.html#ms-top">
+ Massif: a heap profiler</a></h4>
+
<p>
The following is not part of the user manual. It describes how you can
@@ -104,5 +107,5 @@
tools.
-<h4>7 <a href="coregrind_tools.html">
+<h4>8 <a href="coregrind_tools.html">
Valgrind Tools</a></h4>
@@ -112,8 +115,8 @@
have been warned.
-<h4>8 <a href="mc_techdocs.html#mc-techdocs">
+<h4>9 <a href="mc_techdocs.html#mc-techdocs">
The design and implementation of Valgrind</a></h4>
-<h4>9 <a href="cg_techdocs.html#cg-techdocs">
+<h4>10 <a href="cg_techdocs.html#cg-techdocs">
How Cachegrind works</a></h4>
--- valgrind/include/vg_skin.h.base #1.12:1.13
@@ -115,4 +115,8 @@
+/* Path to all our library/aux files */
+extern const Char *VG_(libdir);
+
+
/*====================================================================*/
/*=== Core/skin interface version ===*/
|
|
From: Tom H. <th...@cy...> - 2004-02-14 16:29:48
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> AIUI, the fdsets are bit arrays, with 1024 bits, each bit representing an
> fd; if bit N is set in an array, select will watch fd N appropriately.
> The first arg, n, is the highest N for which a bit is set, plus one.
> Therefore, select() will read at least n bits in each array. Thus, the
> a1/8 is close, but not quite right; it's not rounding up to allow for any
> unused bits at the end of the read bytes. For example, most of the time n
> will be less than 8, in which case the length passed to pre_mem_read will
> be zero! I think it needs to be (a1+7)/8.
First up an fdset only has 1024 bits by default - you are free to
redefine the size before including sys/select.h if your program needs
larger sets. That doesn't actually affect your argument though.
The problem with rounding up instead of down is that it may cause
false positives because there is no guarantee that all the bits in
the final byte will be defined - if I pass 3 as the first argument
that I only have to fill in the first three bits of the first byte
and the others may be undefined as the kernel won't pay any attention
to them.
The problem is that although valgrind tracks definedness at the bit
level the interface that the syscall stuff uses to check it only works
at byte granularity.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 15:56:11
|
Hi,
Here is PRE(select):
PRE(select)
{
/* struct sel_arg_struct {
unsigned long n;
fd_set *inp, *outp, *exp;
struct timeval *tvp;
};
int old_select(struct sel_arg_struct *arg);
*/
SYSCALL_TRACK( pre_mem_read, tid, "select(args)", arg1, 5*sizeof(UInt)
);
{
UInt* arg_struct = (UInt*)arg1;
UInt a1, a2, a3, a4, a5;
a1 = arg_struct[0];
a2 = arg_struct[1];
a3 = arg_struct[2];
a4 = arg_struct[3];
a5 = arg_struct[4];
MAYBE_PRINTF("select ( %d, %p, %p, %p, %p )\n",
a1,a2,a3,a4,a5);
if (a2 != (Addr)NULL)
SYSCALL_TRACK( pre_mem_read, tid, "select(readfds)", a2,
a1/8 /* __FD_SETSIZE/8 */ );
if (a3 != (Addr)NULL)
SYSCALL_TRACK( pre_mem_read, tid, "select(writefds)", a3,
arg1/8 /* __FD_SETSIZE/8 */ );
if (a4 != (Addr)NULL)
SYSCALL_TRACK( pre_mem_read, tid, "select(exceptfds)", a4,
a1/8 /* __FD_SETSIZE/8 */ );
if (a5 != (Addr)NULL)
SYSCALL_TRACK( pre_mem_read, tid, "select(timeout)", a5,
sizeof(struct timeval) );
}
}
First of all, a3's pre_mem_read has arg1/8 in it, instead of a1/8, like
the other two, which looks totally wrong. I think this hasn't raised its
head because select is rarely used, because _newselect is used instead.B
Secondly, and a bigger problem: the a1/8 looks wrong anyway, which
affects both PRE(select) and PRE(_newselect).
AIUI, the fdsets are bit arrays, with 1024 bits, each bit representing an
fd; if bit N is set in an array, select will watch fd N appropriately.
The first arg, n, is the highest N for which a bit is set, plus one.
Therefore, select() will read at least n bits in each array. Thus, the
a1/8 is close, but not quite right; it's not rounding up to allow for any
unused bits at the end of the read bytes. For example, most of the time n
will be less than 8, in which case the length passed to pre_mem_read will
be zero! I think it needs to be (a1+7)/8.
Does this seem right? I'll fix it if people agree.
Thanks.
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-14 15:23:08
|
On Mon, 9 Feb 2004, Jeremy Fitzhardinge wrote: > The check in the POST() functions is to make sure that > the kernel didn't allocate a client FD in Valgrind's reserved range. > Some syscalls, like dup2, allow the client to ask for any FD they want, > and others will just return the next available one, which may be in > Valgrind's range. In these cases we should close the FD and return > ENFILE (or maybe EMFILE). epoll should be the same. Attached patch does this, adding POST() checking for fcntl(), fcntl64(), socketcall.socketpair(), and futex(). Two things I'm not sure about: 1. There's a record_fd_open() in vg_syscalls.c:check_cmsg_for_fds(). I don't know if this needs to be checked; the man page says that recvmsg() can be used to pass fds over sockets... and EMFILE (or ENFILE) aren't among the error values that recvmsg() can return. 2. The man pages for futex() also don't list EMFILE (or ENFILE) as one of the allowed error values. Can someone else take a look at this? Thanks. N |