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
(1) |
3
(1) |
|
4
(1) |
5
(1) |
6
(1) |
7
(1) |
8
(5) |
9
(9) |
10
(1) |
|
11
(1) |
12
(2) |
13
(10) |
14
(4) |
15
(1) |
16
|
17
(1) |
|
18
(1) |
19
(1) |
20
(8) |
21
(1) |
22
(2) |
23
|
24
|
|
25
|
26
(2) |
27
(15) |
28
(12) |
29
(9) |
30
(5) |
31
(5) |
|
From: Julian S. <js...@ac...> - 2009-10-20 21:42:30
|
On Wednesday 14 October 2009, Konstantin Serebryany wrote:
> On Wed, Oct 14, 2009 at 4:05 PM, Julian Seward <js...@ac...> wrote:
> > On Wednesday 14 October 2009, Konstantin Serebryany wrote:
> > > > I did not think about opening this file for the duration of the
> > > > run...
> > :
> > :)
> > :
> > > > I need to check the occupied memory very often so that the tool can
> >
> > ^^^^^^^^^^
> >
> > Actually, you only need to check it when the process' mappings change,
> > or when sbrk happens, since that's the only way(s) the process can
> > acquire more memory. No need for spin-style polling.
> >
> > So .. get your tool to monitor the "new_mem_mmap" and "die_mem_mmap"
>
> This will notify me when the client program does mmap/brk. Right?
Yes.
> But I also need to watch for mmap/brk of valgrind itself. Is it possible?
Hmm, good point. I didn't think of that. Not sure that's easily possible.
How about this Plan B: Get the scheduler to notify you of start/stop
of running of client code (probably you already do):
void VG_(track_start_client_code)(
void(*f)(ThreadId tid, ULong blocks_dispatched)
);
void VG_(track_stop_client_code)(
void(*f)(ThreadId tid, ULong blocks_dispatched)
);
and look at 'blocks_dispatched'. Whenever that changes by (eg)
more than one million, re-read /proc/self/whatever etc.
J
|
|
From: <sv...@va...> - 2009-10-20 18:13:36
|
Author: bart
Date: 2009-10-20 19:13:26 +0100 (Tue, 20 Oct 2009)
New Revision: 10904
Log:
Fixed an assertion failure triggered by running DRD with the command-line option --trace-mutex=yes on a program using one of the ANNOTATE_HAPPENS_*() macros.
Modified:
trunk/drd/drd_mutex.c
Modified: trunk/drd/drd_mutex.c
===================================================================
--- trunk/drd/drd_mutex.c 2009-10-12 13:53:12 UTC (rev 10903)
+++ trunk/drd/drd_mutex.c 2009-10-20 18:13:26 UTC (rev 10904)
@@ -464,6 +464,8 @@
return "mutex";
case mutex_type_spinlock:
return "spinlock";
+ case mutex_type_order_annotation:
+ return "order annotation mutex";
default:
tl_assert(0);
}
|
|
From: Bart V. A. <bar...@gm...> - 2009-10-20 18:10:50
|
On Tue, Oct 20, 2009 at 4:23 PM, Konstantin Serebryany <kon...@gm...> wrote: > > I've recently found a false positive in ThreadSanitizer/Helgrind/DRD. > 1. Access a var. > 2. register atexit callback > 3. call exit > 4. in atexit callback access a var > http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn1175&r=1175#6988 > ==14652== Possible data race during write of size 4 at 0x63f17c by thread #1 > ==14652== at 0x40390A: test152::AtExitCallback() (racecheck_unittest.cc:6994) > ==14652== by 0xE120A5E: exit (in /usr/grte/v1/lib64/libc-2.3.6.so) > ==14652== by 0xE10AB30: (below main) (in /usr/grte/v1/lib64/libc-2.3.6.so) > ==14652== This conflicts with a previous write of size 4 by thread #2 > ==14652== at 0x4150E3: test152::AtExitThread() (racecheck_unittest.cc:6998) > ==14652== by 0x42469F: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:375) > ==14652== by 0xD54A302: mythread_wrapper (hg_intercepts.c:201) > ==14652== by 0xD7530C9: start_thread (in /usr/grte/v1/lib64/libpthread-2.3.6.so) > ==14652== by 0xE1B9811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) Good catch -- thanks for sharing this information. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2009-10-20 14:51:37
|
I've managed to intercept exit. http://code.google.com/p/data-race-test/source/detail?r=1176# You might want to do the same in helgrind/drd. --kcc On Tue, Oct 20, 2009 at 6:23 PM, Konstantin Serebryany < kon...@gm...> wrote: > Hi, > I've recently found a false positive in ThreadSanitizer/Helgrind/DRD. > > 1. Access a var. > 2. register atexit callback > 3. call exit > 4. in atexit callback access a var > > > http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn1175&r=1175#6988 > > ==14652== Possible data race during write of size 4 at 0x63f17c by thread > #1 > ==14652== at 0x40390A: test152::AtExitCallback() > (racecheck_unittest.cc:6994) > ==14652== by 0xE120A5E: exit (in /usr/grte/v1/lib64/libc-2.3.6.so) > ==14652== by 0xE10AB30: (below main) (in /usr/grte/v1/lib64/ > libc-2.3.6.so) > ==14652== This conflicts with a previous write of size 4 by thread #2 > ==14652== at 0x4150E3: test152::AtExitThread() > (racecheck_unittest.cc:6998) > ==14652== by 0x42469F: MyThread::ThreadBody(MyThread*) > (thread_wrappers_pthread.h:375) > ==14652== by 0xD54A302: mythread_wrapper (hg_intercepts.c:201) > ==14652== by 0xD7530C9: start_thread (in /usr/grte/v1/lib64/ > libpthread-2.3.6.so) > ==14652== by 0xE1B9811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) > > The simplest way to fix this is to create a h-b arc between atexit() and > exit(). > I managed to intercept atexit(), but can't do it for exit(). > Is there any dark magic associated with intercepting exit()? > > Thanks, > > --kcc > > > > |
|
From: Konstantin S. <kon...@gm...> - 2009-10-20 14:23:46
|
Hi, I've recently found a false positive in ThreadSanitizer/Helgrind/DRD. 1. Access a var. 2. register atexit callback 3. call exit 4. in atexit callback access a var http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc?spec=svn1175&r=1175#6988 ==14652== Possible data race during write of size 4 at 0x63f17c by thread #1 ==14652== at 0x40390A: test152::AtExitCallback() (racecheck_unittest.cc:6994) ==14652== by 0xE120A5E: exit (in /usr/grte/v1/lib64/libc-2.3.6.so) ==14652== by 0xE10AB30: (below main) (in /usr/grte/v1/lib64/libc-2.3.6.so ) ==14652== This conflicts with a previous write of size 4 by thread #2 ==14652== at 0x4150E3: test152::AtExitThread() (racecheck_unittest.cc:6998) ==14652== by 0x42469F: MyThread::ThreadBody(MyThread*) (thread_wrappers_pthread.h:375) ==14652== by 0xD54A302: mythread_wrapper (hg_intercepts.c:201) ==14652== by 0xD7530C9: start_thread (in /usr/grte/v1/lib64/ libpthread-2.3.6.so) ==14652== by 0xE1B9811: clone (in /usr/grte/v1/lib64/libc-2.3.6.so) The simplest way to fix this is to create a h-b arc between atexit() and exit(). I managed to intercept atexit(), but can't do it for exit(). Is there any dark magic associated with intercepting exit()? Thanks, --kcc |
|
From: John R. <jr...@bi...> - 2009-10-20 13:47:06
|
> I need to run Valgrind on a AVR32 architecture (with Linux OS)... > I was thinking about porting valgrind to AVR32... You need to write a disassembler which interfaces to Valgrind's internal framework for representation of code, and a code generator which interfaces to Valgrind's runtime supervisor. You must also be an expert on the implementation of pthreads (POSIX threads) for AVR32. Plan on a couple years of work. In the vast majority of cases the apps which run on AVR32 using Linux OS also can run on x86 using Linux OS. Therefore, run your apps under Valgrind on x86 (or even x86_64) while you are porting Valgrind to AVR32. You will get 97% of the benefit without waiting for the port to finish. x86 boxes are very inexpensive. They are so inexpensive that any significant application can afford to buy one, use it to run Valgrind, discard the x86 box after ONE YEAR, and still come out ahead. -- |
|
From: maxd\@inwind\.it <ma...@in...> - 2009-10-20 09:27:38
|
Hi guys, I need to run Valgrind on a AVR32 architecture (with Linux OS). As far as I know, there is no support for this architecture, and I was thinking about porting valgrind to AVR32. I read on the valgrind website that porting is not an easy task. Is there any of you which has experience in such a task, and that can provide me with a better estimation of the effort? What roughly needs to be done to port valgrind over a new architecture? Thanks a lot for any information you will provide. Cheers, Massimiliano |
|
From: Bart V. A. <bar...@gm...> - 2009-10-20 07:23:57
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-20 02:00:05 EDT Ended at 2009-10-20 03:23:40 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 448 tests, 45 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (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/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Bart V. A. <bar...@gm...> - 2009-10-19 21:10:32
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-19 02:00:13 EDT Ended at 2009-10-19 17:10:18 EDT Results differ from 24 hours ago Checking out valgrind source tree ... failed Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-10-19T02:00:13} valgrind-new Job ID = 16545.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... failed Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-10-18T02:00:13} valgrind-old Job ID = 16408.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Oct 19 17:07:46 2009 --- new.short Mon Oct 19 17:10:18 2009 *************** *** 5,8 **** ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-10-18T02:00:13} valgrind-old ! Job ID = 16408.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory --- 5,8 ---- ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-10-19T02:00:13} valgrind-new ! Job ID = 16545.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory |
|
From: Bart V. A. <bar...@gm...> - 2009-10-18 08:02:14
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-18 02:24:38 EDT Ended at 2009-10-18 04:01:51 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 448 tests, 45 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (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/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Bart V. A. <bar...@gm...> - 2009-10-17 07:50:19
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-17 02:25:09 EDT Ended at 2009-10-17 03:49:57 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 448 tests, 45 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (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/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Bart V. A. <bar...@gm...> - 2009-10-15 07:52:03
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-15 02:24:28 EDT Ended at 2009-10-15 03:51:41 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 448 tests, 45 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (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/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Konstantin S. <kon...@gm...> - 2009-10-14 12:44:13
|
On Wed, Oct 14, 2009 at 4:05 PM, Julian Seward <js...@ac...> wrote: > On Wednesday 14 October 2009, Konstantin Serebryany wrote: > > > I did not think about opening this file for the duration of the run... > :) > > > I need to check the occupied memory very often so that the tool can > ^^^^^^^^^^ > > Actually, you only need to check it when the process' mappings change, > or when sbrk happens, since that's the only way(s) the process can acquire > more memory. No need for spin-style polling. > > So .. get your tool to monitor the "new_mem_mmap" and "die_mem_mmap" > This will notify me when the client program does mmap/brk. Right? But I also need to watch for mmap/brk of valgrind itself. Is it possible? --kcc > core-tool events. When you get notified of one of those, then check > the memory situation. See Memcheck sources for examples how (it's easy). > > One danger, though; the following race leading to a segfault: > > tool is notified of new_mem_mmap > tool decides to reread /proc/self/status > so it does VG_(malloc) to allocate a buffer > which results in m_mallocfree doing mmap > which results in a new_mem_mmap notification > > We've had problems like this in the past. (I think the above scenario > is impossible, but nevertheless ..) I would strongly suggest that all > the code you have inside your new_mem_mmap does not do any dynamic > mem allocation. Best to read the file, check if need to reduce mem > consumption, if so, set a flag, and exit. Then, elsewhere in your > tool, check the flag, and if set, dump memory, or whatever. > > J > |
|
From: Julian S. <js...@ac...> - 2009-10-14 11:52:44
|
On Wednesday 14 October 2009, Konstantin Serebryany wrote:
> > I did not think about opening this file for the duration of the run... :)
> > I need to check the occupied memory very often so that the tool can
^^^^^^^^^^
Actually, you only need to check it when the process' mappings change,
or when sbrk happens, since that's the only way(s) the process can acquire
more memory. No need for spin-style polling.
So .. get your tool to monitor the "new_mem_mmap" and "die_mem_mmap"
core-tool events. When you get notified of one of those, then check
the memory situation. See Memcheck sources for examples how (it's easy).
One danger, though; the following race leading to a segfault:
tool is notified of new_mem_mmap
tool decides to reread /proc/self/status
so it does VG_(malloc) to allocate a buffer
which results in m_mallocfree doing mmap
which results in a new_mem_mmap notification
We've had problems like this in the past. (I think the above scenario
is impossible, but nevertheless ..) I would strongly suggest that all
the code you have inside your new_mem_mmap does not do any dynamic
mem allocation. Best to read the file, check if need to reduce mem
consumption, if so, set a flag, and exit. Then, elsewhere in your
tool, check the flag, and if set, dump memory, or whatever.
J
|
|
From: Konstantin S. <kon...@gm...> - 2009-10-14 11:30:09
|
On Tue, Oct 13, 2009 at 11:17 PM, Konstantin Serebryany < kon...@gm...> wrote: > On Tue, Oct 13, 2009 at 5:54 PM, John Reiser <jr...@bi...> wrote: > > > > > I need to know how much memory is taken by a valgrind process from > > > inside that process. And I need it to be fast. > > > > How fast? > > > > > One option is to read /proc/self/status and extract the VmSize field. > > > Slow, bad. > > > > Doing a pread(,,,0) and parsing the result via strstr+atoi should take > > about 1 microsecond. > > Hm. Perhaps. > I did not think about opening this file for the duration of the run... :) > I need to check the occupied memory very often so that the tool can > react accordingly when the memory is close to its limit. > pread+strstr+atoi might be fast enough. Need to check... > Valgrind does not have pread(). lseek+read+strstr+strtol is a bit too slow for me, so I have to call it less frequently than I would like to. Any idea how to get VmSize inside valgrind w/o reading /proc/self/status? --kcc > > > > > Open /proc/self/status once at the beginning, > > and keep it open for the zillions of calls you'll be making. > > Or does pread fail for files in /proc? > > > > > Another option is to keep track of valgrind's VG(malloc) and users's > > > malloc, etc. Easy to loose something, bad. > > > > > > If you do not trust valgrind internal code then why run it at all? > > Is there such functionality in valgrind core already? > I need to get the number very close to the one in /proc/self/status:VmSize > > > Thanks! > --kcc > > > > -- > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Bart V. A. <bar...@gm...> - 2009-10-14 07:54:35
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-14 02:27:50 EDT Ended at 2009-10-14 03:54:11 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 448 tests, 45 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (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/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: William C. <wc...@re...> - 2009-10-13 21:08:56
|
William Cohen wrote: > There still seems to be some work required to get this to work with PAPI. For > PAPI tests programs run with valgrind I am getting: > > PAPI Error: pfm_initialize(): not supported. > unknown FAILED > Line # 107 > Error: PAPI_library_init failed > > -Will The papi library is using the cpuid instruction to determine what processor is running on the system. Valgrind doesn't intercepts those instructions and replaces the results. A short program was written to print out the results of cpuid with eax set to 0 and 1. Below one can see the results are very different on the AMD64 machine: [wcohen@dhcp231-201 src]$ /tmp/cpuid cpuid(0) = AuthenticAMD cpuid(1) eax = 00100f23 ebx = 02040800 ecx = 00802009 edx = 178bfbff [wcohen@dhcp231-201 src]$ /home/wcohen/valgrind/valgrind/vg-in-place /tmp/cpuid ==1215== Memcheck, a memory error detector ==1215== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==1215== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==1215== Command: /tmp/cpuid ==1215== cpuid(0) = GenuineIntel cpuid(1) eax = 000006f6 ebx = 00020800 ecx = 0000e3bd edx = bfebfbff ==1215== ==1215== HEAP SUMMARY: ==1215== in use at exit: 0 bytes in 0 blocks ==1215== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==1215== ==1215== All heap blocks were freed -- no leaks are possible ==1215== Would it be possible to add an option to valgrind to allow it use the actual results from cpuid instruction? Use the option would allow accurate identification of the processor and code like PAPI could be tested with valgrind. -Will -Will |
|
From: Konstantin S. <kon...@gm...> - 2009-10-13 19:18:32
|
On Tue, Oct 13, 2009 at 5:54 PM, John Reiser <jr...@bi...> wrote: > > > I need to know how much memory is taken by a valgrind process from > > inside that process. And I need it to be fast. > > How fast? > > > One option is to read /proc/self/status and extract the VmSize field. > > Slow, bad. > > Doing a pread(,,,0) and parsing the result via strstr+atoi should take > about 1 microsecond. Hm. Perhaps. I did not think about opening this file for the duration of the run... :) I need to check the occupied memory very often so that the tool can react accordingly when the memory is close to its limit. pread+strstr+atoi might be fast enough. Need to check... > > Open /proc/self/status once at the beginning, > and keep it open for the zillions of calls you'll be making. > Or does pread fail for files in /proc? > > > Another option is to keep track of valgrind's VG(malloc) and users's > > malloc, etc. Easy to loose something, bad. > > If you do not trust valgrind internal code then why run it at all? Is there such functionality in valgrind core already? I need to get the number very close to the one in /proc/self/status:VmSize Thanks! --kcc > > -- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: William C. <wc...@re...> - 2009-10-13 19:13:15
|
I am planning to use valgrind to check that there are no uninitialized uses of memory with PAPI and the new perf event support available in the 2.6.31 kernels. This morning I wrote up a patch to provide a very basic understanding of the sys_perf_event_open syscall. Attached is the patch for the current valgrind in svn code repository. It has been compiled on x86-64. This patch allows valgrind to work on the perf command in the linux-2.6.32/tools/perf directory. valgrind no longer fails on the perf_event_open syscalls and the perf command appears to collect reasonble data (that data isn't going to be quite accurate with valgrind's binary rewrite). There still seems to be some work required to get this to work with PAPI. For PAPI tests programs run with valgrind I am getting: PAPI Error: pfm_initialize(): not supported. unknown FAILED Line # 107 Error: PAPI_library_init failed -Will |
|
From: John R. <jr...@bi...> - 2009-10-13 13:55:02
|
> I need to know how much memory is taken by a valgrind process from > inside that process. And I need it to be fast. How fast? > One option is to read /proc/self/status and extract the VmSize field. > Slow, bad. Doing a pread(,,,0) and parsing the result via strstr+atoi should take about 1 microsecond. Open /proc/self/status once at the beginning, and keep it open for the zillions of calls you'll be making. Or does pread fail for files in /proc? > Another option is to keep track of valgrind's VG(malloc) and users's > malloc, etc. Easy to loose something, bad. If you do not trust valgrind internal code then why run it at all? -- |
|
From: Konstantin S. <kon...@gm...> - 2009-10-13 12:35:14
|
Hi Valgrind devs, I need to know how much memory is taken by a valgrind process from inside that process. And I need it to be fast. One option is to read /proc/self/status and extract the VmSize field. Slow, bad. Another option is to keep track of valgrind's VG(malloc) and users's malloc, etc. Easy to loose something, bad. Any other suggestion? Thanks, --kcc |
|
From: Bart V. A. <bar...@gm...> - 2009-10-13 07:52:17
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-10-13 02:27:05 EDT Ended at 2009-10-13 03:51:53 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 448 tests, 45 stderr failures, 10 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/linux-syscalls-2007 (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (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/wrap8 (stdout) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) |
|
From: Alexander P. <gl...@go...> - 2009-10-13 06:24:46
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2009-10-13 09:06:01 MSD Ended at 2009-10-13 09:36:30 MSD 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 == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (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) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Tom H. <th...@cy...> - 2009-10-13 02:51:24
|
Nightly build on vauxhall ( x86_64, Fedora 11 ) Started at 2009-10-13 03:20:04 BST Ended at 2009-10-13 03:50:53 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 == 540 tests, 8 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/qt4_rwlock (stderr) exp-ptrcheck/tests/bad_percentify (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 == 540 tests, 7 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/qt4_mutex (stderr) exp-ptrcheck/tests/bad_percentify (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Oct 13 03:34:58 2009 --- new.short Tue Oct 13 03:50:53 2009 *************** *** 8,12 **** ! == 540 tests, 7 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/tc06_two_races_xml (stderr) --- 8,13 ---- ! == 540 tests, 8 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) + helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) *************** *** 14,16 **** helgrind/tests/tc23_bogus_condwait (stderr) ! drd/tests/qt4_mutex (stderr) exp-ptrcheck/tests/bad_percentify (stderr) --- 15,17 ---- helgrind/tests/tc23_bogus_condwait (stderr) ! drd/tests/qt4_rwlock (stderr) exp-ptrcheck/tests/bad_percentify (stderr) |
|
From: Tom H. <th...@cy...> - 2009-10-13 02:48:52
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2009-10-13 03:05:05 BST Ended at 2009-10-13 03:48:29 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 == 530 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |