On Dec 5, 2007 1:29 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
> 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-befo
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-06 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 ..
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-06 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 ...
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-06 03:10:05 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... f
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-06 03:00:02
GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests .
Author: sewardj
Date: 2007-12-06 01:58:05 + (Thu, 06 Dec 2007)
New Revision: 7280
Log:
Another supp.
Modified:
trunk/glibc-2.34567-NPTL-helgrind.supp
/usr/local/etc/subversion//commit-email.pl: `/usr/local/bin/svnlook diff
/home/svn/repos/valgrind -r 7280' failed with this output:
Modif
Author: sewardj
Date: 2007-12-06 02:13:37 + (Thu, 06 Dec 2007)
New Revision: 7281
Log:
Update.
Modified:
trunk/ACKNOWLEDGEMENTS
/usr/local/etc/subversion//commit-email.pl: `/usr/local/bin/svnlook diff
/home/svn/repos/valgrind -r 7281' failed with this output:
Modified: trunk/ACKNOWLEDGE
Author: sewardj
Date: 2007-12-06 02:15:16 + (Thu, 06 Dec 2007)
New Revision: 7282
Log:
--> 3.3.0.RC2.
Modified:
trunk/NEWS
trunk/configure.in
/usr/local/etc/subversion//commit-email.pl: `/usr/local/bin/svnlook diff
/home/svn/repos/valgrind -r 7282' failed with this output:
Modified:
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-06 02:00:01 CET
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... fail
On Thu, 6 Dec 2007, Tom Hughes wrote:
> I get an assertion in memcheck trying to valgrind a windows program
> under wine. This is the current trunk code with a tweaked version of
> the patch from
> http://wiki.winehq.org/Wine_and_Valgrind applied.
>
> I'm just running "valgrind --trace-children=ye
Hmm, Memcheck does very occasionally keel over like that, but the
reason for it has never been established. Is it repeatable?
Were there any invalid reads/writes prior to this point, that might
have trashed any Memcheck-specific data structures?
Nick may well have something more constructive to
I get an assertion in memcheck trying to valgrind a windows program
under wine. This is the current trunk code with a tweaked version of
the patch from
http://wiki.winehq.org/Wine_and_Valgrind applied.
I'm just running "valgrind --trace-children=yes notepad" and I get:
Memcheck: mc_main.c:957 (g
Author: njn
Date: 2007-12-05 21:51:50 + (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
==
> 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
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.
> >
> > G
On Dec 5, 2007 1:19 PM, Julian Seward <[EMAIL PROTECTED]> 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 y
>> 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
#include
#include
#include
// This test case tries to be a
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-variab
> 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
>> 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 <
[EMAIL PROTECTED]> wrote:
> As far as I understand, helgrind is not more than just Eraser :)
>
> For example, the following program does not rep
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
#include
#include
#include
static int COND = 0;
static int
On Dec 5, 2007 10:56 AM, Konstantin Serebryany <
[EMAIL PROTECTED]> 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 co
On Dec 5, 2007 2:24 PM, Julian Seward <[EMAIL PROTECTED]> 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)
> 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
>> 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 out
> 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 ch
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
#include
#include
#include
static int COND = 0;
static pthread_cond_t CV = PTHREAD_COND_I
27 matches
Mail list logo
