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
(9) |
|
2
(12) |
3
(19) |
4
(18) |
5
(22) |
6
(25) |
7
(18) |
8
(24) |
|
9
(16) |
10
(15) |
11
(22) |
12
(7) |
13
(19) |
14
(5) |
15
(8) |
|
16
(7) |
17
(8) |
18
(9) |
19
(7) |
20
(13) |
21
(16) |
22
(7) |
|
23
(10) |
24
(8) |
25
(4) |
26
(4) |
27
(9) |
28
(4) |
29
(5) |
|
30
(8) |
31
(4) |
|
|
|
|
|
|
From: <sv...@va...> - 2007-12-05 21:51:57
|
Author: njn
Date: 2007-12-05 21:51:50 +0000 (Wed, 05 Dec 2007)
New Revision: 7279
Log:
Document flakiness of NON_SIMD_CALL* in comments and the manual.
Modified:
trunk/docs/xml/manual-core-adv.xml
trunk/include/valgrind.h
Modified: trunk/docs/xml/manual-core-adv.xml
===================================================================
--- trunk/docs/xml/manual-core-adv.xml 2007-12-05 01:31:42 UTC (rev 7278)
+++ trunk/docs/xml/manual-core-adv.xml 2007-12-05 21:51:50 UTC (rev 7279)
@@ -200,7 +200,14 @@
client programs.</para>
<para><command>Warning:</command> Only use these if you
- <emphasis>really</emphasis> know what you are doing.</para>
+ <emphasis>really</emphasis> know what you are doing. They aren't
+ entirely reliable, and can cause Valgrind to crash.
+ Generally, your prospects of these working are made higher if the called
+ function does not refer to any global variables, and does not refer to any
+ libc or other functions (printf et al). Any kind of entanglement with libc
+ or dynamic linking is likely to have a bad outcome, for tricky reasons
+ which we've grappled with a lot in the past.
+ </para>
</listitem>
</varlistentry>
Modified: trunk/include/valgrind.h
===================================================================
--- trunk/include/valgrind.h 2007-12-05 01:31:42 UTC (rev 7278)
+++ trunk/include/valgrind.h 2007-12-05 21:51:50 UTC (rev 7279)
@@ -3715,6 +3715,15 @@
Word f(Word tid, Word arg1, Word arg2)
where "Word" is a word-sized type.
+
+ Note that these client requests are not entirely reliable. For example,
+ if you call a function with them that subsequently calls printf(),
+ there's a high chance Valgrind will crash. Generally, your prospects of
+ these working are made higher if the called function does not refer to
+ any global variables, and does not refer to any libc or other functions
+ (printf et al). Any kind of entanglement with libc or dynamic linking is
+ likely to have a bad outcome, for tricky reasons which we've grappled
+ with a lot in the past.
*/
#define VALGRIND_NON_SIMD_CALL0(_qyy_fn) \
__extension__ \
|
|
From: Julian S. <js...@ac...> - 2007-12-05 21:09:17
|
> On Wednesday 05 December 2007 18:10, Christoph Bartoschek wrote: > [...] > > You are right. But lots of code uses condition variables. I would like to > use helgrind on several code parts that use condition variables, but > currently the false positive count is too high. Thanks for the feedback. I might be able to improve the situation, but that will have to wait until after 3.3.0 is released now. J |
|
From: Christoph B. <bar...@or...> - 2007-12-05 17:10:17
|
Am Mittwoch, 5. Dezember 2007 schrieb Julian Seward:
> On Wednesday 05 December 2007 16:32, Christoph Bartoschek wrote:
> > The read of COND in the parent thread happens in a segment that is after
> > the accesses that established the shared-modified state in the
> > happens-before graph.
> >
> > Given that COND should not trigger an error.
>
> But why should we assume that ownership of COND should change from
> shared-modified to exclusively-owned-by-parent at the point of the
> signal/wait pair?
Currently I think that one does not change the state of the variable. But when
one detects an error with the current approach, one would check the
happens-before graph to see whether there really is a problem.
> In this example, it would cause Helgrind to shut up, but it's not obvious
> to me that this is a good thing to do in general.
>
> It would be easy enough (although expensive) to modify Helgrind so that,
> when thread X signals at Y, memory shared by X and Y is made exclusive
> to Y. Is that helpful or correct? I don't know. I don't know what the
> consequences would be, just now.
There is one problem when several signals are emitted. Which one should one
use to establish the happens-before relation? This could make the tool
dependent on the scheduler. For example the following code:
Thread 1: Thread 2:
a. pthread_mutex_lock(mutex); 1. pthread_mutex_lock(mutex);
b. while (COND != 1) { 2. COND = 1;
c. pthread_cond_wait(cv); 3. pthread_cond_signal(cv);
d. } 4. pthread_mutex_unlock(mutex);
e. pthread_mutex_unlock(mutex); 5. pthread_mutex_lock(mutex);
f. COND = 3; 6. COND = 2;
7. pthread_cond_signal(cv);
8. pthread_mutex_unlock(mutex);
If thread 1 wakes up on the first signal in line 3, then there is a problem in
lines f and 6. If thread 1 wakes up on the second signal in line 7, one would
not detect an error. Detecting the error in the first case would be the hard
case in my opinion.
...
> Instead of using source annotations, you can also avoid this
> missing-dependency problem with CVs by using semaphores instead.
> Helgrind tracks dependencies through semaphores exactly. A semaphore
> with an initial value of zero is useful for signalling events between
> threads, without having to mess with these boolean conditions on
> CVs.
You are right. But lots of code uses condition variables. I would like to use
helgrind on several code parts that use condition variables, but currently
the false positive count is too high.
|
|
From: Bart V. A. <bar...@gm...> - 2007-12-05 16:01:51
|
On Dec 5, 2007 1:19 PM, Julian Seward <js...@ac...> wrote: > > > DRD on the other hand looks for possible causes of > > nondeterminism. There are no such issues in the program cv.cc, hence DRD > > does not complain on any of the COND accesses in cv.cc. > > Yes. > > So I have a question: can you clarify what you mean by "possible causes > of nondeterminism"? I have the impression that DRD-style algorithms are > scheduling-sensitive, whereas Helgrind is not (or at least, less so). > > J > If DRD reports a data race, this means that it found conflicting accesses whose order was not defined by synchronization primitives. Such conflicting accesses make the execution of a multithreaded program nondeterministic. And it is right that Helgrind is less sensitive to thread scheduling, and that a pure vector clock based race detector can miss some data races. But the better detection of Helgrind has its price: it runs considerably slower than DRD. It would also be interesting to know how big the chance is that a data race is missed by the vector clock algorithm but that it is detected by the Eraser algorithm. Regards, Bart. |
|
From: Konstantin S. <kon...@gm...> - 2007-12-05 13:52:22
|
>> Can you send a slightly bigger reproducer, which has the child thread
>> doing a few units of work that are passed to it from the parent thread?
Here it is (also attached q.c). Comments embedded.
#define _MULTI_THREADED
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
// This test case tries to be a minimal reproducer of thread pool usage.
//
// We have a permanently working thread worker() which takes
// functions (callbacks) from somewhere (add_callback()) and executes them.
// This thread does not cary any state between callbacks.
// So, logically this is the same as if we destroyed the thread and
recreated it
// each time we have a new callback.
//
// Helgrind can hardly understand this by itself,
// but a simple source annotation should help.
// See ANNOTATE_BEGINNING_OF_CALLBACK/ANNOTATE_END_OF_CALLBACK
//
// This test program has 3 global variables, GLOB1, GLOB2, GLOB3
// GLOB1: no races reported
// GLOB2: helgrind reports a race but ANNOTATE_... should help.
// GLOB3: helgrind reports a race and ANNOTATE_... will not help. Can this
be fixed by other means?
int COND = 0; // condition for
cond_wait() loop
pthread_mutex_t MU = PTHREAD_MUTEX_INITIALIZER; // for CV
pthread_cond_t CV = PTHREAD_COND_INITIALIZER; // works with MU
typedef int (*F)(void);
pthread_mutex_t MU_CB = PTHREAD_MUTEX_INITIALIZER; // for callbacks
static F callback = NULL; // protected by MU
// not protected by locks, synchronized via cond_wait()
static int GLOB1 = 0, GLOB2 = 0, GLOB3 = 0;
// execute untill one of callbacks returns 1
void *worker(void *parm)
{
int stop = 0;
F f;
while(!stop){
pthread_mutex_lock(&MU_CB);
if(callback){
f = callback;
callback = NULL; // we are ready to take next callback
}else{
f = 0;
}
pthread_mutex_unlock(&MU_CB);
if(f){
// ANNOTATE_BEGINNING_OF_CALLBACK (helgrind's client request here)
stop = f();
// ANNOTATE_END_OF_CALLBACK (helgrind's client request here)
}
sleep(1); // don't burn CPU. Real thread pool will block instead of
sleeping.
}
}
void add_callback(F f)
{
pthread_mutex_lock(&MU_CB);
assert(callback == NULL);
callback = f;
pthread_mutex_unlock(&MU_CB);
}
int callback_do_something_usefull()
{
sleep(2); // we want waiter to get there first
GLOB1 = 2; // no race is reported
GLOB2 = 2; // helgrind reports a race
pthread_mutex_lock(&MU);
GLOB3 = 2;
pthread_mutex_unlock(&MU);
pthread_mutex_lock(&MU);
COND = 1;
pthread_cond_signal(&CV);
pthread_mutex_unlock(&MU);
return 0; // continue
}
int callback_finish_thread()
{
return 1; // stop
}
int main(int argc, char **argv)
{
pthread_t threadid;
// accessed before pthread_create()
GLOB1 = 1;
pthread_create(&threadid, NULL, worker, NULL);
// accessed after pthread_create() but before
ANNOTATE_BEGINNING_OF_CALLBACK
GLOB2 = 1;
add_callback(callback_do_something_usefull);
pthread_mutex_lock(&MU);
GLOB3 = 1;
pthread_mutex_unlock(&MU);
// now we wait untill callback_do_something_usefull() signals.
pthread_mutex_lock(&MU);
while (COND != 1) {
pthread_cond_wait(&CV, &MU);
}
pthread_mutex_unlock(&MU);
// at this point callback_do_something_usefull() has signalled
// and will never write to any of these variables again.
// I beleive that worker() can be removed from TSETs of
// all tree variables.
//
// It is still possible that callback_do_something_usefull()
// did not exit yet and we did not execute ANNOTATE_END_OF_CALLBACK.
//
//
// Currently, helgrind has the following info:
// GLOB1: Exclusive(main)
// GLOB2: ShMod(tset={main, worker}, lset={})
// GLOB3: ShMod(tset={main, worker}, lset={MU})
GLOB1 = 2; // helgrind does *not* report a race
GLOB2 = 2; // helgrind already reported a race in
callback_do_something_usefull()
GLOB3 = 2; // helgrind reports race here
// fprintf(stderr, "GLOB1: %d\n", GLOB1);
// fprintf(stderr, "GLOB2: %d\n", GLOB2);
// fprintf(stderr, "GLOB3: %d\n", GLOB3);
// real program will give more usefull callbacks here
add_callback(callback_finish_thread);
pthread_join(threadid, NULL);
return 0;
}
On Dec 5, 2007 2:24 PM, Julian Seward <js...@ac...> wrote:
>
> > COND is accessed before cond_signal() in child thread
>
> yes
>
> > and after cond_wait() in parent thread.
>
> no:
>
> while (COND != 1) {
> fprintf(stderr, "Wait: COND: %d\n", COND);
> pthread_cond_wait(&CV, &MU);
> }
>
> If the parent only accessed COND after cond_wait, then Helgrind would
> not complain, as then it would understand that "exclusive ownership" is
> transferred from child to parent by the signal/wait pair. However, both
> parent and child access it before the signal/wait pair, COND is marked
> as being in shared ownership, and the above doesn't apply.
>
> > >> If you change the order of these two lines, to
> >
> > Sure. But thread_join is not what is usually done in presence of thread
> > pools...
> > Threads tend to live forever.
> > This program is just a short reproducer.
>
> Yes. I suspect what you are seeing is a problem to do with memory
> recycling. See Helgrind manual Sec 7.5 point 2.
>
> Can you send a slightly bigger reproducer, which has the child thread
> doing a few units of work that are passed to it from the parent thread?
>
> J
>
|
|
From: Julian S. <js...@ac...> - 2007-12-05 12:30:24
|
On Wednesday 05 December 2007 13:17, Konstantin Serebryany wrote: > >> As far as I understand, helgrind is not more than just Eraser :) > helgrind is more than just Eraser :) True. Helgrind is Eraser + usage of happens-before dependencies resulting from thread creation, joinage, condition-variable signalling (to the extent these dependencies are visible), and through semaphore events, + the ability to transfer memory from shared states to exclusive ownership states at pthread_join points. J |
|
From: Julian S. <js...@ac...> - 2007-12-05 12:19:53
|
> I can be wrong, but my understanding is that the Eraser algorithm > (helgrind) reports any conflicting accesses to shared variables that are > not protected by proper locking, so I expect helgrind to complain on the > last COND access. Yes. > DRD on the other hand looks for possible causes of > nondeterminism. There are no such issues in the program cv.cc, hence DRD > does not complain on any of the COND accesses in cv.cc. Yes. So I have a question: can you clarify what you mean by "possible causes of nondeterminism"? I have the impression that DRD-style algorithms are scheduling-sensitive, whereas Helgrind is not (or at least, less so). J |
|
From: Konstantin S. <kon...@gm...> - 2007-12-05 12:17:23
|
>> As far as I understand, helgrind is not more than just Eraser :)
helgrind is more than just Eraser :)
On Dec 5, 2007 3:16 PM, Konstantin Serebryany <
kon...@gm...> wrote:
> As far as I understand, helgrind is not more than just Eraser :)
>
> For example, the following program does not report any race, while GLOB is
> *not* protected by any lock.
>
> % cat cv2.cc
> #define _MULTI_THREADED
> #include <pthread.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> static int COND = 0;
> static int GLOB = 0;
> static pthread_cond_t CV = PTHREAD_COND_INITIALIZER;
> static pthread_mutex_t MU = PTHREAD_MUTEX_INITIALIZER;
>
> void *run_pm(void*) {
> sleep(2); // we want waiter to get there first
> GLOB = 1;
> pthread_mutex_lock(&MU);
> COND++;
> fprintf(stderr, "Signal: COND: %d\n", COND);
> pthread_cond_signal(&CV);
> pthread_mutex_unlock(&MU);
> return NULL;
> }
>
> int main() {
> pthread_t threadid;
> GLOB = 2;
> pthread_create(&threadid, NULL, run_pm, NULL);
>
> pthread_mutex_lock(&MU);
> while (COND != 1) {
> pthread_cond_wait(&CV, &MU);
> }
> pthread_mutex_unlock(&MU);
>
> GLOB = 2;
> fprintf(stderr, "GLOB: %d\n", GLOB);
> pthread_join(threadid, NULL);
> return 0;
> }
> % g++ -g cv2.cc -lpthread ; ~/race/valgrind32orig/Inst/bin/valgrind -q
> --tool=helgrind ./a.out
> Signal: COND: 1
> GLOB: 2
> %
>
>
>
> On Dec 5, 2007 3:10 PM, Bart Van Assche <bar...@gm...> wrote:
>
> > On Dec 5, 2007 10:56 AM, Konstantin Serebryany <
> > kon...@gm...> wrote:
> >
> > > Hi Julian, all,
> > >
> > > I get a report about a race from helgrind, while everything looks well
> > > synchronized to me.
> > > Am I wrong?
> > >
> >
> > I can be wrong, but my understanding is that the Eraser algorithm
> > (helgrind) reports any conflicting accesses to shared variables that are not
> > protected by proper locking, so I expect helgrind to complain on the last
> > COND access. DRD on the other hand looks for possible causes of
> > nondeterminism. There are no such issues in the program cv.cc, hence DRD
> > does not complain on any of the COND accesses in cv.cc.
> >
> > Regards,
> >
> > Bart Van Assche.
>
>
>
|
|
From: Konstantin S. <kon...@gm...> - 2007-12-05 12:16:38
|
As far as I understand, helgrind is not more than just Eraser :)
For example, the following program does not report any race, while GLOB is
*not* protected by any lock.
% cat cv2.cc
#define _MULTI_THREADED
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
static int COND = 0;
static int GLOB = 0;
static pthread_cond_t CV = PTHREAD_COND_INITIALIZER;
static pthread_mutex_t MU = PTHREAD_MUTEX_INITIALIZER;
void *run_pm(void*) {
sleep(2); // we want waiter to get there first
GLOB = 1;
pthread_mutex_lock(&MU);
COND++;
fprintf(stderr, "Signal: COND: %d\n", COND);
pthread_cond_signal(&CV);
pthread_mutex_unlock(&MU);
return NULL;
}
int main() {
pthread_t threadid;
GLOB = 2;
pthread_create(&threadid, NULL, run_pm, NULL);
pthread_mutex_lock(&MU);
while (COND != 1) {
pthread_cond_wait(&CV, &MU);
}
pthread_mutex_unlock(&MU);
GLOB = 2;
fprintf(stderr, "GLOB: %d\n", GLOB);
pthread_join(threadid, NULL);
return 0;
}
% g++ -g cv2.cc -lpthread ; ~/race/valgrind32orig/Inst/bin/valgrind -q
--tool=helgrind ./a.out
Signal: COND: 1
GLOB: 2
%
On Dec 5, 2007 3:10 PM, Bart Van Assche <bar...@gm...> wrote:
> On Dec 5, 2007 10:56 AM, Konstantin Serebryany <
> kon...@gm...> wrote:
>
> > Hi Julian, all,
> >
> > I get a report about a race from helgrind, while everything looks well
> > synchronized to me.
> > Am I wrong?
> >
>
> I can be wrong, but my understanding is that the Eraser algorithm
> (helgrind) reports any conflicting accesses to shared variables that are not
> protected by proper locking, so I expect helgrind to complain on the last
> COND access. DRD on the other hand looks for possible causes of
> nondeterminism. There are no such issues in the program cv.cc, hence DRD
> does not complain on any of the COND accesses in cv.cc.
>
> Regards,
>
> Bart Van Assche.
|
|
From: Bart V. A. <bar...@gm...> - 2007-12-05 12:10:47
|
On Dec 5, 2007 10:56 AM, Konstantin Serebryany < kon...@gm...> wrote: > Hi Julian, all, > > I get a report about a race from helgrind, while everything looks well > synchronized to me. > Am I wrong? > I can be wrong, but my understanding is that the Eraser algorithm (helgrind) reports any conflicting accesses to shared variables that are not protected by proper locking, so I expect helgrind to complain on the last COND access. DRD on the other hand looks for possible causes of nondeterminism. There are no such issues in the program cv.cc, hence DRD does not complain on any of the COND accesses in cv.cc. Regards, Bart Van Assche. |
|
From: Konstantin S. <kon...@gm...> - 2007-12-05 11:58:28
|
On Dec 5, 2007 2:24 PM, Julian Seward <js...@ac...> wrote:
>
> > COND is accessed before cond_signal() in child thread
>
> yes
>
> > and after cond_wait() in parent thread.
>
> no:
>
> while (COND != 1) {
> fprintf(stderr, "Wait: COND: %d\n", COND);
> pthread_cond_wait(&CV, &MU);
> }
>
> If the parent only accessed COND after cond_wait, then Helgrind would
> not complain, as then it would understand that "exclusive ownership" is
> transferred from child to parent by the signal/wait pair. However, both
> parent and child access it before the signal/wait pair, COND is marked
> as being in shared ownership, and the above doesn't apply.
Yes, COND *is* accessed before cond_wait() by the parent thread -- it the
condition of the cond_wait's while loop :)
Therefore, I agree, it is ShMod by both threads with nonempty lockset.
But once we did signal/wait we only access COND in the parent thread.
why can't we transfer ShMod->Exclusive after cond_signal/cond_wait().
More generally if a thread #x does cond_signal and thread #y does cond_wait
we transfer ShMod(#x, #y, #z) -> ShMod(#y, #z).
Will we loose any true positives with such logic?
>
>
> > >> If you change the order of these two lines, to
> >
> > Sure. But thread_join is not what is usually done in presence of thread
> > pools...
> > Threads tend to live forever.
> > This program is just a short reproducer.
>
> Yes. I suspect what you are seeing is a problem to do with memory
> recycling. See Helgrind manual Sec 7.5 point 2.
I did put VALGRIND_HG_CLEAN_MEMORY everywhere I could find :)
I don't think this is it.
>
>
> Can you send a slightly bigger reproducer, which has the child thread
> doing a few units of work that are passed to it from the parent thread?
>
I should (and will) certainly do this, but it's rather hard...
We have our own mutexes and our own thread pool with callback machinery.
The point is that we usually call thread_join at the very end of the program
and helgrind's logic related to thread_join does not kick in.
As I understand, _VG_USERREQ__HG_PTHREAD_JOIN_POST will work only if the
thread actually did quit.
Do you think it is possible to implement a similar request to indicate the
end of ThreadPool's callback?
Again, I'll try to come back with a reproducer.
>
> J
>
|
|
From: Julian S. <js...@ac...> - 2007-12-05 11:25:39
|
> COND is accessed before cond_signal() in child thread
yes
> and after cond_wait() in parent thread.
no:
while (COND != 1) {
fprintf(stderr, "Wait: COND: %d\n", COND);
pthread_cond_wait(&CV, &MU);
}
If the parent only accessed COND after cond_wait, then Helgrind would
not complain, as then it would understand that "exclusive ownership" is
transferred from child to parent by the signal/wait pair. However, both
parent and child access it before the signal/wait pair, COND is marked
as being in shared ownership, and the above doesn't apply.
> >> If you change the order of these two lines, to
>
> Sure. But thread_join is not what is usually done in presence of thread
> pools...
> Threads tend to live forever.
> This program is just a short reproducer.
Yes. I suspect what you are seeing is a problem to do with memory
recycling. See Helgrind manual Sec 7.5 point 2.
Can you send a slightly bigger reproducer, which has the child thread
doing a few units of work that are passed to it from the parent thread?
J
|
|
From: Konstantin S. <kon...@gm...> - 2007-12-05 10:51:09
|
>> Helgrind cannot know that the child thread (run_pm) does not access COND again after the pthread_cond_signal I thought the logic related to cond_wait() is supposed to catch this. COND is accessed before cond_signal() in child thread and after cond_wait() in parent thread. If COND is accessed outside of critical sections in both threads (but still, before cond_signal in child and after cond_wait in parent), helgrind is quiet. >> If you change the order of these two lines, to Sure. But thread_join is not what is usually done in presence of thread pools... Threads tend to live forever. This program is just a short reproducer. --kcc On Dec 5, 2007 1:41 PM, Julian Seward <js...@ac...> wrote: > > > I get a report about a race from helgrind, while everything looks well > > synchronized to me. > > Am I wrong? > > > fprintf(stderr, "COND: %d\n", COND); > > pthread_join(threadid, NULL); > > The problem is here. By the time you get here, Helgrind knows that > COND has been accessed by both parent and child threads, and MU is > used to protect it. But now you are using it without a lock. > > Helgrind cannot know that the child thread (run_pm) does not access > COND again after the pthread_cond_signal (how could it know this > without doing static analysis of the child's code?) > > If you change the order of these two lines, to > > > pthread_join(threadid, NULL); > > fprintf(stderr, "COND: %d\n", COND); > > then it stops complaining. Because now the pthread_join tells Helgrind > that the child can no longer access COND. That means, after the > pthread_join, > the parent is the only thread able to access COND, so it is OK for it > to access COND without a lock. > > J > |
|
From: Julian S. <js...@ac...> - 2007-12-05 10:41:52
|
> I get a report about a race from helgrind, while everything looks well > synchronized to me. > Am I wrong? > fprintf(stderr, "COND: %d\n", COND); > pthread_join(threadid, NULL); The problem is here. By the time you get here, Helgrind knows that COND has been accessed by both parent and child threads, and MU is used to protect it. But now you are using it without a lock. Helgrind cannot know that the child thread (run_pm) does not access COND again after the pthread_cond_signal (how could it know this without doing static analysis of the child's code?) If you change the order of these two lines, to > pthread_join(threadid, NULL); > fprintf(stderr, "COND: %d\n", COND); then it stops complaining. Because now the pthread_join tells Helgrind that the child can no longer access COND. That means, after the pthread_join, the parent is the only thread able to access COND, so it is OK for it to access COND without a lock. J |
|
From: Konstantin S. <kon...@gm...> - 2007-12-05 09:56:31
|
Hi Julian, all,
I get a report about a race from helgrind, while everything looks well
synchronized to me.
Am I wrong?
Thanks,
--kcc
% cat cv.cc
#define _MULTI_THREADED
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
static int COND = 0;
static pthread_cond_t CV = PTHREAD_COND_INITIALIZER;
static pthread_mutex_t MU = PTHREAD_MUTEX_INITIALIZER;
void *run_pm(void*) {
sleep(2); // we want waiter to get there first
pthread_mutex_lock(&MU);
COND++;
fprintf(stderr, "Signal: COND: %d\n", COND);
pthread_cond_signal(&CV);
pthread_mutex_unlock(&MU);
return NULL;
}
int main() {
pthread_t threadid;
pthread_create(&threadid, NULL, run_pm, NULL);
pthread_mutex_lock(&MU);
while (COND != 1) {
fprintf(stderr, "Wait: COND: %d\n", COND);
pthread_cond_wait(&CV, &MU);
}
pthread_mutex_unlock(&MU);
fprintf(stderr, "COND: %d\n", COND);
pthread_join(threadid, NULL);
return 0;
}
% g++ -g cv.cc -lpthread
% ~/race/valgrind32orig/Inst/bin/valgrind --tool=helgrind ./a.out
==31530== Helgrind, a thread error detector.
==31530== Copyright (C) 2007-2007, and GNU GPL'd, by OpenWorks LLP et al.
==31530== Using LibVEX rev 1793, a library for dynamic binary translation.
==31530== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==31530== Using valgrind-3.3.0.RC1, a dynamic binary instrumentation
framework.
==31530== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==31530== For more details, rerun with: -v
==31530==
Wait: COND: 0
Signal: COND: 1
==31530== Thread #1 is the program's root thread
==31530==
==31530== Thread #2 was created
==31530== at 0x4FF1A4D8: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
==31530== by 0x410B37E2: pthread_create@@GLIBC_2.1 (in
/lib/tls/i686/cmov/libpthread-2.3.6.so)
==31530== by 0x47A749A: pthread_create@* (hg_intercepts.c:213)
==31530== by 0x80486FC: main (cv.cc:23)
==31530==
==31530== Possible data race during read of size 4 at 0x8049AB8
==31530== at 0x8048754: main (cv.cc:32)
==31530== Old state: shared-modified by threads #1, #2
==31530== New state: shared-modified by threads #1, #2
==31530== Reason: this thread, #1, holds no consistent locks
==31530== Last consistently used lock for 0x8049AB8 was first observed
==31530== at 0x47A7916: pthread_mutex_lock (hg_intercepts.c:408)
==31530== by 0x8048708: main (cv.cc:25)
COND: 1
==31530==
==31530== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 16 from 4)
%
|
|
From: Tom H. <th...@cy...> - 2007-12-05 03:57:00
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-05 03:15:02 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 == 321 tests, 62 stderr failures, 1 stdout failure, 28 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (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/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (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-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/mremap (stderr) none/tests/mremap2 (stdout) 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...> - 2007-12-05 03:32:13
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-05 03:05:05 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 == 355 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-05 03:26:48
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-05 03:10:05 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 == 355 tests, 10 stderr failures, 4 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-05 03:13:51
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-05 03:00:02 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 == 357 tests, 25 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) 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/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) |
|
From: <js...@ac...> - 2007-12-05 01:46:19
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-05 02:00:01 CET 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 == 288 tests, 27 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) 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/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (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) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: <sv...@va...> - 2007-12-05 01:31:41
|
Author: sewardj
Date: 2007-12-05 01:31:42 +0000 (Wed, 05 Dec 2007)
New Revision: 7278
Log:
Rename a header file.
Added:
trunk/exp-omega/exp-omega.h
Removed:
trunk/exp-omega/omega.h
Modified:
trunk/exp-omega/Makefile.am
trunk/exp-omega/o_main.c
trunk/exp-omega/o_replace_memops.c
Modified: trunk/exp-omega/Makefile.am
===================================================================
--- trunk/exp-omega/Makefile.am 2007-12-05 01:19:20 UTC (rev 7277)
+++ trunk/exp-omega/Makefile.am 2007-12-05 01:31:42 UTC (rev 7278)
@@ -130,7 +130,7 @@
oincludedir = $(includedir)/valgrind
-oinclude_HEADERS = omega.h
+oinclude_HEADERS = exp-omega.h
noinst_HEADERS =
Copied: trunk/exp-omega/exp-omega.h (from rev 7276, trunk/exp-omega/omega.h)
===================================================================
--- trunk/exp-omega/exp-omega.h (rev 0)
+++ trunk/exp-omega/exp-omega.h 2007-12-05 01:31:42 UTC (rev 7278)
@@ -0,0 +1,61 @@
+
+/*------------------------------------------------------------------------*/
+/*--- Definitions needing to be shared between source files. ---*/
+/*--- omega.h ---*/
+/*------------------------------------------------------------------------*/
+
+/*
+ This file is part of Omega, a Valgrind tool for instantly detecting
+ memory leaks.
+
+ Copyright (C) 2006-2007 Bryan "Brain Murders" Meredith
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307, USA.
+
+ The GNU General Public License is contained in the file COPYING.
+
+ The current maintainer is Rich Coe <ric...@me...>.
+*/
+
+#ifndef __omega_h
+#define __omega_h
+
+#include "valgrind.h"
+
+/*
+** Setup client request calls so we can track entering and leaving main().
+*/
+typedef
+enum {
+ VG_USERREQ__ENTERING_MAIN = VG_USERREQ_TOOL_BASE('O','M'),
+ VG_USERREQ__LEAVING_MAIN
+} Vg_OmegaClientRequest;
+
+#define VALGRIND_DO_ENTER_MAIN \
+ {unsigned int _qzz_res; \
+ VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, \
+ VG_USERREQ__ENTERING_MAIN, \
+ 0, 0, 0, 0, 0); \
+ }
+
+#define VALGRIND_DO_LEAVE_MAIN \
+ {unsigned int _qzz_res; \
+ VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, \
+ VG_USERREQ__LEAVING_MAIN, \
+ 0, 0, 0, 0, 0); \
+ }
+
+#endif
Modified: trunk/exp-omega/o_main.c
===================================================================
--- trunk/exp-omega/o_main.c 2007-12-05 01:19:20 UTC (rev 7277)
+++ trunk/exp-omega/o_main.c 2007-12-05 01:31:42 UTC (rev 7278)
@@ -63,7 +63,7 @@
#include "libvex_guest_offsets.h"
-#include "omega.h"
+#include "exp-omega.h"
/*
** A little sanity in a mad, mad world.
Modified: trunk/exp-omega/o_replace_memops.c
===================================================================
--- trunk/exp-omega/o_replace_memops.c 2007-12-05 01:19:20 UTC (rev 7277)
+++ trunk/exp-omega/o_replace_memops.c 2007-12-05 01:31:42 UTC (rev 7278)
@@ -37,7 +37,7 @@
#include <stdio.h>
#include "pub_tool_basics.h"
#include "valgrind.h"
-#include "omega.h"
+#include "exp-omega.h"
/* ---------------------------------------------------------------------
We have our own versions of these functions so that we can correctly
Deleted: trunk/exp-omega/omega.h
===================================================================
--- trunk/exp-omega/omega.h 2007-12-05 01:19:20 UTC (rev 7277)
+++ trunk/exp-omega/omega.h 2007-12-05 01:31:42 UTC (rev 7278)
@@ -1,61 +0,0 @@
-
-/*------------------------------------------------------------------------*/
-/*--- Definitions needing to be shared between source files. ---*/
-/*--- omega.h ---*/
-/*------------------------------------------------------------------------*/
-
-/*
- This file is part of Omega, a Valgrind tool for instantly detecting
- memory leaks.
-
- Copyright (C) 2006-2007 Bryan "Brain Murders" Meredith
-
- This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License as
- published by the Free Software Foundation; either version 2 of the
- License, or (at your option) any later version.
-
- This program is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
- 02111-1307, USA.
-
- The GNU General Public License is contained in the file COPYING.
-
- The current maintainer is Rich Coe <ric...@me...>.
-*/
-
-#ifndef __omega_h
-#define __omega_h
-
-#include "valgrind.h"
-
-/*
-** Setup client request calls so we can track entering and leaving main().
-*/
-typedef
-enum {
- VG_USERREQ__ENTERING_MAIN = VG_USERREQ_TOOL_BASE('O','M'),
- VG_USERREQ__LEAVING_MAIN
-} Vg_OmegaClientRequest;
-
-#define VALGRIND_DO_ENTER_MAIN \
- {unsigned int _qzz_res; \
- VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, \
- VG_USERREQ__ENTERING_MAIN, \
- 0, 0, 0, 0, 0); \
- }
-
-#define VALGRIND_DO_LEAVE_MAIN \
- {unsigned int _qzz_res; \
- VALGRIND_DO_CLIENT_REQUEST(_qzz_res, 0, \
- VG_USERREQ__LEAVING_MAIN, \
- 0, 0, 0, 0, 0); \
- }
-
-#endif
|
|
From: <sv...@va...> - 2007-12-05 01:19:25
|
Author: sewardj Date: 2007-12-05 01:19:20 +0000 (Wed, 05 Dec 2007) New Revision: 7277 Log: Update expected outputs. Use new naming scheme now permitted by tests/vg_regtest. Added: trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-amd64 trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-x86 Removed: trunk/memcheck/tests/malloc_free_fill.stderr.exp Modified: trunk/memcheck/tests/Makefile.am Modified: trunk/memcheck/tests/Makefile.am =================================================================== --- trunk/memcheck/tests/Makefile.am 2007-12-04 21:35:55 UTC (rev 7276) +++ trunk/memcheck/tests/Makefile.am 2007-12-05 01:19:20 UTC (rev 7277) @@ -67,7 +67,8 @@ long_namespace_xml.vgtest long_namespace_xml.stdout.exp \ long_namespace_xml.stderr.exp \ malloc_free_fill.vgtest malloc_free_fill.stdout.exp \ - malloc_free_fill.stderr.exp \ + malloc_free_fill.stderr.exp-glibc25-amd64 \ + malloc_free_fill.stderr.exp-glibc25-x86 \ malloc_usable.stderr.exp malloc_usable.vgtest \ malloc1.stderr.exp malloc1.vgtest \ malloc2.stderr.exp malloc2.vgtest \ Deleted: trunk/memcheck/tests/malloc_free_fill.stderr.exp =================================================================== --- trunk/memcheck/tests/malloc_free_fill.stderr.exp 2007-12-04 21:35:55 UTC (rev 7276) +++ trunk/memcheck/tests/malloc_free_fill.stderr.exp 2007-12-05 01:19:20 UTC (rev 7277) @@ -1,57 +0,0 @@ - -test simple malloc/free: -Use of uninitialised value of size 8 - at 0x........: _itoa_word (in /...libc...) - by 0x........: ... - by 0x........: ... - by 0x........: ... - by 0x........: ... - by 0x........: main (malloc_free_fill.c:17) - -Conditional jump or move depends on uninitialised value(s) - at 0x........: _itoa_word (in /...libc...) - by 0x........: ... - by 0x........: ... - by 0x........: ... - by 0x........: ... - by 0x........: main (malloc_free_fill.c:17) - -Conditional jump or move depends on uninitialised value(s) - at 0x........: vfprintf (in /...libc...) - by 0x........: ... - by 0x........: ... - by 0x........: ... - by 0x........: main (malloc_free_fill.c:17) -(should be malloc-filled) a[4] = 55555555 - -Invalid read of size 4 - at 0x........: main (malloc_free_fill.c:20) - Address 0x........ is 20 bytes inside a block of size 40 free'd - at 0x........: free (vg_replace_malloc.c:...) - by 0x........: main (malloc_free_fill.c:19) -(should be free-filled) a[5] = 77777777 -test realloc-larger: -(should be malloc-filled) r[25] = 55555555 - -Invalid read of size 4 - at 0x........: main (malloc_free_fill.c:33) - Address 0x........ is 104 bytes inside a block of size 120 free'd - at 0x........: realloc (vg_replace_malloc.c:...) - by 0x........: main (malloc_free_fill.c:31) -(should be free-filled) oldr[26] = 77777777 -(should be malloc-filled) r[35] = 55555555 -test realloc-smaller: -(should be malloc-filled) r[25] = 55555555 - -Invalid read of size 4 - at 0x........: main (malloc_free_fill.c:49) - Address 0x........ is not stack'd, malloc'd or (recently) free'd -(should be free-filled) oldr[26] = 77777777 -test calloc: -(should be zero) a[42] = 0 - -ERROR SUMMARY: 67 errors from 6 contexts (suppressed: 0 from 0) -malloc/free: in use at exit: 0 bytes in 0 blocks. -malloc/free: 6 allocs, 6 frees, 920 bytes allocated. -For a detailed leak analysis, rerun with: --leak-check=yes -For counts of detected errors, rerun with: -v Copied: trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-amd64 (from rev 7276, trunk/memcheck/tests/malloc_free_fill.stderr.exp) =================================================================== --- trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-amd64 (rev 0) +++ trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-amd64 2007-12-05 01:19:20 UTC (rev 7277) @@ -0,0 +1,57 @@ + +test simple malloc/free: +Use of uninitialised value of size 8 + at 0x........: _itoa_word (in /...libc...) + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: main (malloc_free_fill.c:17) + +Conditional jump or move depends on uninitialised value(s) + at 0x........: _itoa_word (in /...libc...) + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: main (malloc_free_fill.c:17) + +Conditional jump or move depends on uninitialised value(s) + at 0x........: vfprintf (in /...libc...) + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: main (malloc_free_fill.c:17) +(should be malloc-filled) a[4] = 55555555 + +Invalid read of size 4 + at 0x........: main (malloc_free_fill.c:20) + Address 0x........ is 20 bytes inside a block of size 40 free'd + at 0x........: free (vg_replace_malloc.c:...) + by 0x........: main (malloc_free_fill.c:19) +(should be free-filled) a[5] = 77777777 +test realloc-larger: +(should be malloc-filled) r[25] = 55555555 + +Invalid read of size 4 + at 0x........: main (malloc_free_fill.c:33) + Address 0x........ is 104 bytes inside a block of size 120 free'd + at 0x........: realloc (vg_replace_malloc.c:...) + by 0x........: main (malloc_free_fill.c:31) +(should be free-filled) oldr[26] = 77777777 +(should be malloc-filled) r[35] = 55555555 +test realloc-smaller: +(should be malloc-filled) r[25] = 55555555 + +Invalid read of size 4 + at 0x........: main (malloc_free_fill.c:49) + Address 0x........ is not stack'd, malloc'd or (recently) free'd +(should be free-filled) oldr[26] = 77777777 +test calloc: +(should be zero) a[42] = 0 + +ERROR SUMMARY: 67 errors from 6 contexts (suppressed: 0 from 0) +malloc/free: in use at exit: 0 bytes in 0 blocks. +malloc/free: 6 allocs, 6 frees, 920 bytes allocated. +For a detailed leak analysis, rerun with: --leak-check=yes +For counts of detected errors, rerun with: -v Added: trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-x86 =================================================================== --- trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-x86 (rev 0) +++ trunk/memcheck/tests/malloc_free_fill.stderr.exp-glibc25-x86 2007-12-05 01:19:20 UTC (rev 7277) @@ -0,0 +1,57 @@ + +test simple malloc/free: +Use of uninitialised value of size 4 + at 0x........: _itoa_word (in /...libc...) + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: main (malloc_free_fill.c:17) + +Conditional jump or move depends on uninitialised value(s) + at 0x........: _itoa_word (in /...libc...) + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: main (malloc_free_fill.c:17) + +Conditional jump or move depends on uninitialised value(s) + at 0x........: vfprintf (in /...libc...) + by 0x........: ... + by 0x........: ... + by 0x........: ... + by 0x........: main (malloc_free_fill.c:17) +(should be malloc-filled) a[4] = 55555555 + +Invalid read of size 4 + at 0x........: main (malloc_free_fill.c:20) + Address 0x........ is 20 bytes inside a block of size 40 free'd + at 0x........: free (vg_replace_malloc.c:...) + by 0x........: main (malloc_free_fill.c:19) +(should be free-filled) a[5] = 77777777 +test realloc-larger: +(should be malloc-filled) r[25] = 55555555 + +Invalid read of size 4 + at 0x........: main (malloc_free_fill.c:33) + Address 0x........ is 104 bytes inside a block of size 120 free'd + at 0x........: realloc (vg_replace_malloc.c:...) + by 0x........: main (malloc_free_fill.c:31) +(should be free-filled) oldr[26] = 77777777 +(should be malloc-filled) r[35] = 55555555 +test realloc-smaller: +(should be malloc-filled) r[25] = 55555555 + +Invalid read of size 4 + at 0x........: main (malloc_free_fill.c:49) + Address 0x........ is not stack'd, malloc'd or (recently) free'd +(should be free-filled) oldr[26] = 77777777 +test calloc: +(should be zero) a[42] = 0 + +ERROR SUMMARY: 67 errors from 6 contexts (suppressed: 0 from 0) +malloc/free: in use at exit: 0 bytes in 0 blocks. +malloc/free: 6 allocs, 6 frees, 920 bytes allocated. +For a detailed leak analysis, rerun with: --leak-check=yes +For counts of detected errors, rerun with: -v |