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) |