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: Doug R. <df...@nl...> - 2004-02-16 11:51:10
|
On Mon, 2004-02-16 at 09:31, Doug Rabson wrote:
> On Mon, 2004-02-16 at 06:57, Jeremy Fitzhardinge wrote:
> > On Sat, 2004-02-14 at 11:15, Doug Rabson wrote:
> > > 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).
> >
> > I think the problem is that Valgrind is conflating two levels of
> > abstraction. There's the core scheduler's notion of a thread being
> > "running" or "blocked", and there's the pthreads library's view of what
> > state the thread is in with respect to pthreads objects. I assume that
> > "real" pthreads blocks in a syscall whenever it can be interrupted by a
> > signal, and the syscall restart stuff (or whatever) decides what to do
> > if it has been interrupted, what the new state of the pthreads object
> > is, etc.
>
> I have about half an answer (which I haven't thought through) where the
> actual state transition from WaitCV to Runnable is made by the scheduler
> (i.e. in the context of the waiting thread) rather than by the
> signaller. It would go something like this:
>
> If a thread is in WaitCV but has no associated_cv
> If associated_mx is not held
> lock associated_mx
> clear associated_mx
> state is Runnable
> else
> state is WaitMX
>
> Then in release_N_threads_waiting_on_cond, just check the value of
> associated_cv (not the thread state). It would simply clear the
> associated_cv variable and leave the mutex manipulation to the
> scheduler. It would mean being squeaky clean about nulling associated_cv
> when not waiting on a cond but I think that is done already.
I'm going with this change for now (which at least gets my tester's
program running properly). Sorry about the FreeBSD-isms - this diff
isn't taken from the valgrind cvs.
--- valgrind/branches/dfr/coregrind/vg_scheduler.c 2004-02-12
20:13:40 UTC (rev 270)
+++ valgrind/branches/dfr/coregrind/vg_scheduler.c 2004-02-16
11:43:41 UTC (rev 271)
@@ -31,6 +31,7 @@
#include "valgrind.h" /* for VG_USERREQ__RUNNING_ON_VALGRIND and
VG_USERREQ__DISCARD_TRANSLATIONS, and
others */
#include "vg_include.h"
+#include <pthread.h>
/* BORKAGE/ISSUES as of 29 May 02
@@ -134,6 +135,16 @@
static void scheduler_sanity ( void );
static void do_pthread_cond_timedwait_TIMEOUT ( ThreadId tid );
+#ifdef __linux__
+#define MUTEX(mutex) (mutex)
+#endif
+#ifdef __FreeBSD__
+#define MUTEX(mutex) (*mutex)
+typedef int _pthread_descr;
+#define PTHREAD_MUTEX_ERRORCHECK_NP PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE
+#endif
+
/*
---------------------------------------------------------------------
Helper functions for the scheduler.
------------------------------------------------------------------
*/
@@ -916,6 +927,38 @@
while (True) {
tid_next++;
if (tid_next >= VG_N_THREADS) tid_next = 1;
+
+ /* Deal with threads woken up from waiting on a cond. */
+ if (VG_(threads)[tid_next].status == VgTs_WaitCV
+ && VG_(threads)[tid_next].associated_cv == NULL) {
+ pthread_mutex_t* mx;
+
+ mx = VG_(threads)[tid_next].associated_mx;
+ vg_assert(mx != NULL);
+
+ VG_TRACK( pre_mutex_lock, tid_next, mx );
+ if (MUTEX(mx)->__m_owner == VG_INVALID_THREADID) {
+ /* Currently unheld; hand it out to thread i. */
+ vg_assert(MUTEX(mx)->__m_count == 0);
+ VG_(threads)[tid_next].status = VgTs_Runnable;
+ VG_(threads)[tid_next].associated_cv = NULL;
+ VG_(threads)[tid_next].associated_mx = NULL;
+ MUTEX(mx)->__m_owner = (_pthread_descr)tid_next;
+ MUTEX(mx)->__m_count = 1;
+ /* .m_edx already holds pth_cond_wait success value
(0) */
+
+ VG_TRACK( post_mutex_lock, tid_next, mx );
+
+ } else {
+ /* Currently held. Make thread i be blocked on it. */
+ vg_assert(MUTEX(mx)->__m_count > 0);
+ VG_(threads)[tid_next].status = VgTs_WaitMX;
+ VG_(threads)[tid_next].associated_cv = NULL;
+ VG_(threads)[tid_next].associated_mx = mx;
+ SET_PTHREQ_RETVAL(tid_next, 0); /* pth_cond_wait
success value */
+ }
+ }
+
if (VG_(threads)[tid_next].status == VgTs_Sleeping
|| VG_(threads)[tid_next].status == VgTs_WaitSys
|| VG_(threads)[tid_next].status == VgTs_WaitCV)
@@ -1312,7 +1355,6 @@
The pthread implementation.
------------------------------------------------------------------
*/
-#include <pthread.h>
#include <errno.h>
#define VG_PTHREAD_STACK_MIN \
@@ -1999,16 +2041,6 @@
deals with that for us.
*/
-#ifdef __linux__
-#define MUTEX(mutex) (mutex)
-#endif
-#ifdef __FreeBSD__
-#define MUTEX(mutex) (*mutex)
-typedef int _pthread_descr;
-#define PTHREAD_MUTEX_ERRORCHECK_NP PTHREAD_MUTEX_ERRORCHECK
-#define PTHREAD_MUTEX_RECURSIVE_NP PTHREAD_MUTEX_RECURSIVE
-#endif
-
/* Helper fns ... */
static
void release_one_thread_waiting_on_mutex ( pthread_mutex_t* mutex,
@@ -2355,8 +2387,7 @@
for (i = 1; i < VG_N_THREADS; i++) {
if (VG_(threads)[i].status == VgTs_Empty)
continue;
- if (VG_(threads)[i].status == VgTs_WaitCV
- && VG_(threads)[i].associated_cv == cond)
+ if (VG_(threads)[i].associated_cv == cond)
break;
}
vg_assert(i <= VG_N_THREADS);
@@ -2366,43 +2397,22 @@
return;
}
+ VG_(threads)[i].associated_cv = NULL;
mx = VG_(threads)[i].associated_mx;
vg_assert(mx != NULL);
- VG_TRACK( pre_mutex_lock, i, mx );
-
if (MUTEX(mx)->__m_owner == VG_INVALID_THREADID) {
- /* Currently unheld; hand it out to thread i. */
- vg_assert(MUTEX(mx)->__m_count == 0);
- VG_(threads)[i].status = VgTs_Runnable;
- VG_(threads)[i].associated_cv = NULL;
- VG_(threads)[i].associated_mx = NULL;
- MUTEX(mx)->__m_owner = (_pthread_descr)i;
- MUTEX(mx)->__m_count = 1;
- /* .m_edx already holds pth_cond_wait success value (0) */
-
- VG_TRACK( post_mutex_lock, i, mx );
-
if (VG_(clo_trace_pthread_level) >= 1) {
VG_(sprintf)(msg_buf, "%s cv %p: RESUME with mx %p",
caller, cond, mx );
print_pthread_event(i, msg_buf);
}
-
} else {
- /* Currently held. Make thread i be blocked on it. */
- vg_assert(MUTEX(mx)->__m_count > 0);
- VG_(threads)[i].status = VgTs_WaitMX;
- VG_(threads)[i].associated_cv = NULL;
- VG_(threads)[i].associated_mx = mx;
- SET_PTHREQ_RETVAL(i, 0); /* pth_cond_wait success value */
-
if (VG_(clo_trace_pthread_level) >= 1) {
VG_(sprintf)(msg_buf, "%s cv %p: BLOCK for mx %p",
caller, cond, mx );
print_pthread_event(i, msg_buf);
}
-
}
n_to_release--;
@@ -3359,7 +3369,6 @@
#endif
} else
if (VG_(threads)[i].status == VgTs_WaitCV) {
- vg_assert(cv != NULL);
vg_assert(mx != NULL);
} else {
/* Unfortunately these don't hold true when a sighandler is
|
|
From: Doug R. <df...@nl...> - 2004-02-16 09:35:27
|
On Mon, 2004-02-16 at 06:57, Jeremy Fitzhardinge wrote: > On Sat, 2004-02-14 at 11:15, Doug Rabson wrote: > > 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). > > I think the problem is that Valgrind is conflating two levels of > abstraction. There's the core scheduler's notion of a thread being > "running" or "blocked", and there's the pthreads library's view of what > state the thread is in with respect to pthreads objects. I assume that > "real" pthreads blocks in a syscall whenever it can be interrupted by a > signal, and the syscall restart stuff (or whatever) decides what to do > if it has been interrupted, what the new state of the pthreads object > is, etc. I have about half an answer (which I haven't thought through) where the actual state transition from WaitCV to Runnable is made by the scheduler (i.e. in the context of the waiting thread) rather than by the signaller. It would go something like this: If a thread is in WaitCV but has no associated_cv If associated_mx is not held lock associated_mx clear associated_mx state is Runnable else state is WaitMX Then in release_N_threads_waiting_on_cond, just check the value of associated_cv (not the thread state). It would simply clear the associated_cv variable and leave the mutex manipulation to the scheduler. It would mean being squeaky clean about nulling associated_cv when not waiting on a cond but I think that is done already. > > Which raises a question: what happens if a thread blocks in a CV, is > interrupted by a signal, and the signal handler does a longjmp to > somewhere else? What state is the CV left in? A silly one. FreeBSD's libc_r woule probably have the thread still on the cond's queue from a quick look at the code. |
|
From: Jeremy F. <je...@go...> - 2004-02-16 07:06:19
|
On Sat, 2004-02-14 at 07:20, Nicholas Nethercote wrote: > 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. I think these are both documentation oversights. The kernel will definitely return ENFILE from futex(); I'm not sure about recvmsg; it might return EBADF (which would be confusing). J |
|
From: Jeremy F. <je...@go...> - 2004-02-16 07:01:09
|
On Sat, 2004-02-14 at 11:15, Doug Rabson wrote: > 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). I think the problem is that Valgrind is conflating two levels of abstraction. There's the core scheduler's notion of a thread being "running" or "blocked", and there's the pthreads library's view of what state the thread is in with respect to pthreads objects. I assume that "real" pthreads blocks in a syscall whenever it can be interrupted by a signal, and the syscall restart stuff (or whatever) decides what to do if it has been interrupted, what the new state of the pthreads object is, etc. Which raises a question: what happens if a thread blocks in a CV, is interrupted by a signal, and the signal handler does a longjmp to somewhere else? What state is the CV left in? J |
|
From: <js...@ac...> - 2004-02-16 04:09:28
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-02-16 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fi tls.c: In function `main': tls.c:92: warning: comparison between signed and unsigned if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow -g -I../../include -MT tls2.o -MD -MP -MF ".deps/tls2.Tpo" \ -c -o tls2.o `test -f 'tls2.c' || echo './'`tls2.c; \ then mv ".deps/tls2.Tpo" ".deps/tls2.Po"; \ else rm -f ".deps/tls2.Tpo"; exit 1; \ fi gcc -Winline -Wall -Wshadow -g -I../../include -o tls -Wl,-rpath,. tls.o tls2.o tls.so -lpthread tls.so: undefined reference to `___tls_get_addr' collect2: ld returned 1 exit status make[4]: *** [tls] Error 1 make[4]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sewardj/ValgrindABT/valgrind' make: *** [check] Error 2 |
|
From: <js...@ac...> - 2004-02-16 03:56:17
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-02-16 03:50:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow then mv -f ".deps/tls.Tpo" ".deps/tls.Po"; \ else rm -f ".deps/tls.Tpo"; exit 1; \ fi if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow -g -I../../include -MT tls2.o -MD -MP -MF ".deps/tls2.Tpo" \ -c -o tls2.o `test -f 'tls2.c' || echo './'`tls2.c; \ then mv -f ".deps/tls2.Tpo" ".deps/tls2.Po"; \ else rm -f ".deps/tls2.Tpo"; exit 1; \ fi gcc -Winline -Wall -Wshadow -g -I../../include -o tls -Wl,-rpath,. tls.o tls2.o tls.so -lpthread tls.so: undefined reference to `___tls_get_addr' collect2: ld returned 1 exit status make[4]: *** [tls] Error 1 make[4]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sewardj/ValgrindABT/valgrind' make: *** [check] Error 2 |