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
(33) |
2
(15) |
3
(20) |
4
(22) |
5
(13) |
|
6
(12) |
7
(32) |
8
(17) |
9
(31) |
10
(21) |
11
(7) |
12
(13) |
|
13
(13) |
14
(12) |
15
(10) |
16
(8) |
17
(7) |
18
(28) |
19
(5) |
|
20
(5) |
21
(7) |
22
(11) |
23
(7) |
24
(13) |
25
(7) |
26
(7) |
|
27
(7) |
28
(15) |
29
(30) |
30
(21) |
31
(6) |
|
|
|
From: Andrei S. <and...@gm...> - 2008-07-28 22:29:04
|
On Tue, Jul 29, 2008 at 1:16 AM, Nicholas Nethercote < nj...@cs...> wrote: > On Mon, 28 Jul 2008, Andrei Soare wrote: > > I need help again, this time the problem is with threads. I have added a >> skip list structure to ms_main.c and have encountered a thread error in >> the >> function that adds a node to a list. >> I would really appreciate some help. >> > > Rather than debug your code for you, I'll suggest that you use either the > VgHashTable data structure (include/pub_tool_hashtable.h) or the OSet > (include/pub_tool_oset.h) data structure. OSet is a bit more general but > also a bit harder to understand how to use it. > > Nick > That will not help me, I don't need a hash table. I need a data structure which will keep all the allocations sorted (so it has to be an ordered list) and I need fast searching within that list (for that, skip lists are the best). Otherwise, I have tried implementing a simple linked list (in which i can search with linear complexity) and it takes hours to run a program under valgrind. Skip lists have a complexity of O( log(n) ). -- Andrei Soare |
|
From: Nicholas N. <nj...@cs...> - 2008-07-28 22:16:25
|
On Mon, 28 Jul 2008, Andrei Soare wrote: > I need help again, this time the problem is with threads. I have added a > skip list structure to ms_main.c and have encountered a thread error in the > function that adds a node to a list. > I would really appreciate some help. Rather than debug your code for you, I'll suggest that you use either the VgHashTable data structure (include/pub_tool_hashtable.h) or the OSet (include/pub_tool_oset.h) data structure. OSet is a bit more general but also a bit harder to understand how to use it. Nick |
|
From: Jim C. <cl...@cc...> - 2008-07-28 21:00:16
|
Any ideas on how to support speculative errors in Valgrind? I have a situation where I detect a situation where an error maybe occurring but I'm unable to be sure until sometime later. Currently I'm handling this with some custom error code where I grab the ExecContext when I think the error might occur and use it later when reporting the error. I'd like to switch my code to Valgrind's error manager / suppression API but I don't see how this is possible right now since I can't control there "where" portion of the error. I could place my ExeContext into a custom extra structure but then I don't see how to match it to a suppression. Thanks, Jim |
|
From: Andrei S. <and...@gm...> - 2008-07-28 15:04:38
|
Hello,
I need help again, this time the problem is with threads. I have added a
skip list structure to ms_main.c and have encountered a thread error in the
function that adds a node to a list.
I would really appreciate some help.
Here is the code that adds a new node to a skip list. I have added comments
to show you where exactly the program crashes.
static
void add_node (SizeT szB, void *ptr)
{
Allocation_List *node;
int i, nodeH;
if (first == NULL) { // first build a sentinel node
first = (Allocation_List *) VG_(malloc)(sizeof(Allocation_List));
first->szB = 0;
first->ptr = NULL;
first->prev = NULL;
first->next = (Allocation_List **) VG_(malloc)(sizeof(Allocation_List
*) * (MAX_H+1));
for (i = 0; i <= MAX_H; i++) first->next[i] = NULL;
path = (Allocation_List **) VG_(malloc)(sizeof(Allocation_List *) *
(MAX_H+1));
}
if (search_node(ptr)) return; // this updates the path variable and
node = build_node (szB, ptr, &nodeH);
if (path[0]->next[0] != NULL)
path[0]->next[0]->prev = node;
VG_(printf)("check\n");
tl_assert(node->next);
tl_assert(path[0]->next);
node->prev = path[0];
node->next[0] = path[0]->next[0]; // this instruction was added for purely
testing purposes; it executes well
VG_(printf)("hmm %d %p %p %p %p
\n",nodeH,node->next,path[0]->next,node->next[0],path[0]->next[0]);
for (i = 0; i <= nodeH; i++) {
VG_(printf)("check\n\n");
node->next[i] = path[i]->next[i]; // this is where the program
crashes, when it attempts to execute this line of code. initially, i = 0, so
the instruction is the same as that before the for loop, which executes
well; weird ...
VG_(printf)("last check\n"); // this is never executed
path[i]->next[i] = node;
}
And here are the definitions of the variables and data types used:
typedef struct _Allocation_List {
struct _Allocation_List **next, *prev;
SizeT szB;
void *ptr;
} Allocation_List;
#define MAX_H 20 // maximum level of skip list
int H = 0; // current maximum
level of skip list
Allocation_List *first = NULL, *last = NULL; // first and last elements of
skip list
Allocation_List **path; // path[i]=element on level i,
previous
// to the
searched element
Finally, here is the output i get when i use valgrind --tool=massif:
check
hmm 0 0x61C190A8 0x61C1A9A8 0x0 0x0
hmm 0 0x61C190A8 0x61C1A9A8 0x0 0x0
check
--9227-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) -
exiting
--9227-- si_code=1; Faulting address: 0x0; sp: 0x6279AEDC
valgrind: the 'impossible' happened:
Killed by fatal signal
==9227== at 0x3800093A: add_node (ms_main.c:1548)
==9227== by 0x380028F8: new_block (ms_main.c:1615)
==9227== by 0x3802290F: vgPlain_scheduler (scheduler.c:1269)
==9227== by 0x38036868: run_a_thread_NORETURN (syswrap-linux.c:89)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==9227== at 0x40220D8: malloc (vg_replace_malloc.c:207)
==9227== by 0x4B83C35: (within /lib/tls/i686/cmov/libc-2.7.so)
==9227== by 0x4B83EDF: bindtextdomain (in /lib/tls/i686/cmov/libc-2.7.so)
==9227== by 0x53FD719: gpg_err_init (in /lib/libgpg-error.so.0.3.0)
==9227== by 0x53FDB64: (within /lib/libgpg-error.so.0.3.0)
==9227== by 0x53FD59B: (within /lib/libgpg-error.so.0.3.0)
==9227== by 0x400D99F: (within /lib/ld-2.7.so)
==9227== by 0x400DAD2: (within /lib/ld-2.7.so)
==9227== by 0x400084E: (within /lib/ld-2.7.so)
Thank you.
Regards,
Andrei Soare
|
|
From: <sv...@va...> - 2008-07-28 14:55:31
|
Author: bart Date: 2008-07-28 15:55:38 +0100 (Mon, 28 Jul 2008) New Revision: 8465 Log: Attempted to make DRD documentation compatible with pdfxmltex. Added note about g_thread_init(). Modified: trunk/drd/docs/drd-manual.xml Modified: trunk/drd/docs/drd-manual.xml =================================================================== --- trunk/drd/docs/drd-manual.xml 2008-07-28 12:03:53 UTC (rev 8464) +++ trunk/drd/docs/drd-manual.xml 2008-07-28 14:55:38 UTC (rev 8465) @@ -806,106 +806,15 @@ </para> <para> -There is one message that needs further explanation, namely sending a -signal to a condition variable while no lock is held on the mutex -associated with the signal. Consider e.g. the example <xref -linkend="Racy use of pthread_cond_wait()"></xref>. In this example the -code in thread 1 passes if <literal>flag != 0</literal>, or waits -until it has been signaled by thread 2. If however the code of thread -1 is scheduled after the <literal>pthread_mutex_unlock()</literal> -call in thread 2 and before thread 2 calls -<literal>pthread_cond_signal()</literal>, thread 1 will block -indefinitely. The code in the example <xref linkend="Correct use of -pthread_cond_wait()"></xref> never blocks indefinitely. -</para> - -<para> -Because most calls of <function>pthread_cond_signal()</function> or +Regarding the message DRD prints about sending a signal to a condition +variable while no lock is held on the mutex associated with the +signal: DRD reports this because some calls of +<function>pthread_cond_signal()</function> or <function>pthread_cond_broadcast()</function> while no lock is held on -the mutex associated with the condition variable are racy, by default -DRD reports such calls. +the mutex associated with the condition variable introduce subtle race +conditions. </para> -<table - frame="none" - id="Racy use of pthread_cond_wait()" - xreflabel="Racy use of pthread_cond_wait()" -> -<title>Racy use of pthread_cond_wait()</title> -<!-- -<tgroup cols='2' align='left' colsep='1' rowsep='1'> - <colspec colname='thread1'/> - <colspec colname='thread2'/> - <thead> - <row> - <entry align="center">Thread 1</entry> - <entry align="center">Thread 2</entry> - </row> - </thead> - <tbody> - <row> - <entry> -<programlisting><![CDATA[ -pthread_mutex_lock(&mutex); -if (! flag) - pthread_cond_wait(&cond, &mutex); -pthread_mutex_unlock(&mutex); -]]></programlisting> - </entry> - <entry> -<programlisting><![CDATA[ -pthread_mutex_lock(&mutex); -flag = 1; -pthread_mutex_unlock(&mutex); -pthread_cond_signal(&cond); -]]></programlisting> - </entry> - </row> - </tbody> -</tgroup> ---> -</table> - -<table - frame="none" - id="Correct use of pthread_cond_wait()" - xreflabel="Correct use of pthread_cond_wait()" -> -<title>Correct use of pthread_cond_wait()</title> -<!-- -<tgroup cols='2' align='left' colsep='1' rowsep='1'> - <colspec colname='thread1'/> - <colspec colname='thread2'/> - <thead> - <row> - <entry align="center">Thread 1</entry> - <entry align="center">Thread 2</entry> - </row> - </thead> - <tbody> - <row> - <entry> -<programlisting><![CDATA[ -pthread_mutex_lock(&mutex); -if (! flag) - pthread_cond_wait(&cond, &mutex); -pthread_mutex_unlock(&mutex); -]]></programlisting> - </entry> - <entry> -<programlisting><![CDATA[ -pthread_mutex_lock(&mutex); -flag = 1; -pthread_cond_signal(&cond); -pthread_mutex_unlock(&mutex); -]]></programlisting> - </entry> - </row> - </tbody> -</tgroup> ---> -</table> - </sect2> @@ -998,8 +907,16 @@ <para> GNOME applications use the threading primitives provided by the -<computeroutput>glib</computeroutput> library. This library is built -on top of POSIX threads, and is hence directly supported by DRD. +<computeroutput>glib</computeroutput> and +<computeroutput>gthread</computeroutput> libraries. These libraries +are built on top of POSIX threads, and hence are directly supported by +DRD. Please keep in mind that you have to call +<function>g_thread_init()</function> before creating any threads, or +DRD will report several data races on glib functions. See also the +<ulink +url="http://library.gnome.org/devel/glib/stable/glib-Threads.html">GLib +Reference Manual</ulink> for more information about +<function>g_thread_init()</function>. </para> <para> @@ -1025,11 +942,8 @@ supported, and there are known problems with multithreading support in Qt3. As an example, using QString objects in more than one thread will trigger race reports (this has been confirmed by Trolltech -- see also -Trolltech task (bug report) number 206152. -<!-- - <ulink -url="http://trolltech.com/developer/task-tracker/index_html?id=206152&method=entry">#206152</ulink>). ---> +Trolltech task <ulink +url="http://trolltech.com/developer/task-tracker/index_html">#206152</ulink>). </para> <para> |
|
From: Bart V. A. <bar...@gm...> - 2008-07-28 14:15:07
|
Some DRD regression tests link against the Qt4 library, and that is why there is a test for Qt4 in Valgrind's configure.in. That test currently uses built-in autoconf macro's like AC_TRY_COMPILE(). This is a rather cumbersome way to find out e.g. the path of Qt4 include files. Would it be OK to rewrite this test using the autoconf macro's provided by pkg-config, e.g. PKG_CHECK_EXISTS() ? This would add an extra requirement however when building Valgrind, and I'm not sure where to document this. Bart. |
|
From: <sv...@va...> - 2008-07-28 12:03:46
|
Author: bart Date: 2008-07-28 13:03:53 +0100 (Mon, 28 Jul 2008) New Revision: 8464 Log: Sorted noinst_HEADERS filenames alphabetically. Modified: trunk/drd/Makefile.am Modified: trunk/drd/Makefile.am =================================================================== --- trunk/drd/Makefile.am 2008-07-28 11:36:11 UTC (rev 8463) +++ trunk/drd/Makefile.am 2008-07-28 12:03:53 UTC (rev 8464) @@ -111,6 +111,7 @@ noinst_HEADERS = \ drd_barrier.h \ + drd_bitmap.c \ drd_bitmap.h \ drd_clientobj.h \ drd_clientreq.h \ @@ -119,18 +120,17 @@ drd_malloc_wrappers.h \ drd_mutex.h \ drd_rwlock.h \ + drd_segment.c \ drd_segment.h \ drd_semaphore.h \ drd_suppression.h \ + drd_thread.c \ drd_thread.h \ + drd_thread_bitmap.h \ drd_track.h \ + drd_vc.c \ drd_vc.h \ - pub_drd_bitmap.h \ - drd_bitmap.c \ - drd_segment.c \ - drd_thread.c \ - drd_vc.c \ - drd_thread_bitmap.h + pub_drd_bitmap.h drd_x86_linux_SOURCES = $(DRD_SOURCES) drd_x86_linux_CPPFLAGS = $(AM_CPPFLAGS_X86_LINUX) |
|
From: <sv...@va...> - 2008-07-28 11:36:02
|
Author: bart Date: 2008-07-28 12:36:11 +0100 (Mon, 28 Jul 2008) New Revision: 8463 Log: Reverted commit 8448. Modified: trunk/drd/tests/Makefile.am Modified: trunk/drd/tests/Makefile.am =================================================================== --- trunk/drd/tests/Makefile.am 2008-07-28 11:35:10 UTC (rev 8462) +++ trunk/drd/tests/Makefile.am 2008-07-28 11:36:11 UTC (rev 8463) @@ -238,9 +238,9 @@ tc24_nonzero_sem \ trylock -#if HAVE_QTCORE -#check_PROGRAMS += qt4_mutex qt4_rwlock qt4_semaphore -#endif +if HAVE_QTCORE +check_PROGRAMS += qt4_mutex qt4_rwlock qt4_semaphore +endif if HAVE_OPENMP check_PROGRAMS += omp_matinv omp_prime @@ -316,17 +316,17 @@ pth_spinlock_SOURCES = pth_spinlock.c pth_spinlock_LDADD = -lpthread -#if HAVE_QTCORE -#qt4_mutex_SOURCES = qt4_mutex.cpp -#qt4_mutex_LDADD = -lQtCore -lpthread -# -#qt4_rwlock_SOURCES = qt4_rwlock.cpp -#qt4_rwlock_LDADD = -lQtCore -lpthread -# -#qt4_semaphore_SOURCES = qt4_semaphore.cpp -#qt4_semaphore_LDADD = -lQtCore -lpthread -#endif +if HAVE_QTCORE +qt4_mutex_SOURCES = qt4_mutex.cpp +qt4_mutex_LDADD = -lQtCore -lpthread +qt4_rwlock_SOURCES = qt4_rwlock.cpp +qt4_rwlock_LDADD = -lQtCore -lpthread + +qt4_semaphore_SOURCES = qt4_semaphore.cpp +qt4_semaphore_LDADD = -lQtCore -lpthread +endif + recursive_mutex_SOURCES = recursive_mutex.c recursive_mutex_LDADD = -lpthread |
|
From: <sv...@va...> - 2008-07-28 11:35:06
|
Author: bart
Date: 2008-07-28 12:35:10 +0100 (Mon, 28 Jul 2008)
New Revision: 8462
Log:
Added configure test for QMutex::tryLock(int).
Modified:
trunk/configure.in
trunk/drd/tests/qt4_mutex.cpp
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2008-07-28 11:23:38 UTC (rev 8461)
+++ trunk/configure.in 2008-07-28 11:35:10 UTC (rev 8462)
@@ -1234,7 +1234,7 @@
fi
-# Checks for header files.
+# Checks for C header files.
AC_HEADER_STDC
AC_CHECK_HEADERS([ \
endian.h \
@@ -1251,6 +1251,7 @@
sys/types.h \
])
+# Checks for C++ header files.
AC_LANG(C++)
AC_CHECK_HEADERS([ \
QtCore/QMutex \
@@ -1425,6 +1426,31 @@
AM_CONDITIONAL([HAVE_QTCORE], [test x$ac_have_qtcore = xyes])
+# Test for QMutex::tryLock(int), which has been introduced in Qt 4.3.
+# See also http://doc.trolltech.com/4.3/qmutex.html.
+if test x$ac_have_qtcore = xyes; then
+ AC_MSG_CHECKING([for Qt4 QMutex::tryLock(int)])
+ AC_LANG(C++)
+ AC_TRY_COMPILE([
+ #include <QtCore/QMutex>
+ ],
+ [
+ QMutex M;
+ M.tryLock(1);
+ M.unlock();
+ return 0;
+ ],
+ [
+ AC_MSG_RESULT([yes])
+ AC_DEFINE([HAVE_QTCORE_QMUTEX_TRYLOCK_INT], [1], [Define to 1 if the installed version of Qt4 provides QMutex::tryLock(int).])
+ ],
+ [
+ AC_MSG_RESULT([no])
+ ])
+ AC_LANG(C)
+fi
+
+
# -------------------- ok. We're done. --------------------
AC_OUTPUT(
Modified: trunk/drd/tests/qt4_mutex.cpp
===================================================================
--- trunk/drd/tests/qt4_mutex.cpp 2008-07-28 11:23:38 UTC (rev 8461)
+++ trunk/drd/tests/qt4_mutex.cpp 2008-07-28 11:35:10 UTC (rev 8462)
@@ -4,6 +4,7 @@
#define _GNU_SOURCE
#endif
+#include "config.h"
#include <QtCore/QMutex> // class QMutex
#include <QtCore/QThread> // class QThread
#include <cassert>
@@ -56,12 +57,14 @@
M.unlock();
M.unlock();
}
+#if defined(HAVE_QTCORE_QMUTEX_TRYLOCK_INT)
{
QMutex M(QMutex::NonRecursive);
assert(M.tryLock(1));
assert(! M.tryLock(1));
M.unlock();
}
+#endif
pthread_barrier_init(&s_barrier, 0, n_threads);
s_pMutex = new QMutex();
|
|
From: <sv...@va...> - 2008-07-28 11:23:36
|
Author: bart Date: 2008-07-28 12:23:38 +0100 (Mon, 28 Jul 2008) New Revision: 8461 Log: Fixed race condition. Modified: trunk/drd/tests/pth_inconsistent_cond_wait.c Modified: trunk/drd/tests/pth_inconsistent_cond_wait.c =================================================================== --- trunk/drd/tests/pth_inconsistent_cond_wait.c 2008-07-24 10:34:12 UTC (rev 8460) +++ trunk/drd/tests/pth_inconsistent_cond_wait.c 2008-07-28 11:23:38 UTC (rev 8461) @@ -37,13 +37,14 @@ pthread_t tid1; pthread_t tid2; - sem_init(&s_sem, 0, 2); + sem_init(&s_sem, 0, 0); pthread_cond_init(&s_cond, 0); pthread_mutex_init(&s_mutex1, 0); pthread_mutex_init(&s_mutex2, 0); pthread_create(&tid1, 0, &thread1, 0); pthread_create(&tid2, 0, &thread2, 0); sem_wait(&s_sem); + sem_wait(&s_sem); pthread_mutex_lock(&s_mutex1); pthread_mutex_lock(&s_mutex2); pthread_mutex_unlock(&s_mutex2); |
|
From: Tom H. <th...@cy...> - 2008-07-28 03:26:35
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-07-28 03:15:07 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 345 tests, 60 stderr failures, 1 stdout failure, 29 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin1-yes (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (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/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-names (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2008-07-28 03:12:00
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-07-28 03:20:07 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 443 tests, 8 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (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 == 443 tests, 9 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/pth_inconsistent_cond_wait (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Jul 28 03:53:53 2008 --- new.short Mon Jul 28 04:12:07 2008 *************** *** 8,10 **** ! == 443 tests, 9 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/file_locking (stderr) --- 8,10 ---- ! == 443 tests, 8 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/file_locking (stderr) *************** *** 18,20 **** helgrind/tests/tc22_exit_w_lock (stderr) - drd/tests/pth_inconsistent_cond_wait (stderr) --- 18,19 ---- |
|
From: Tom H. <th...@cy...> - 2008-07-28 03:01:07
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-07-28 03:05:11 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 6 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-07-28 02:56:29
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-07-28 03:27:37 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 441 tests, 10 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/pth_inconsistent_cond_wait (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 == 441 tests, 9 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Jul 28 03:47:41 2008 --- new.short Mon Jul 28 03:56:37 2008 *************** *** 8,10 **** ! == 441 tests, 9 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) --- 8,10 ---- ! == 441 tests, 10 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) *************** *** 23,24 **** --- 23,25 ---- helgrind/tests/tc22_exit_w_lock (stderr) + drd/tests/pth_inconsistent_cond_wait (stderr) |
|
From: Tom H. <th...@cy...> - 2008-07-28 02:50:45
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-07-28 03:00:10 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 443 tests, 32 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/atomic_var (stderr) |