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
(12) |
2
(9) |
|
3
(23) |
4
(24) |
5
(9) |
6
(7) |
7
(5) |
8
(2) |
9
(6) |
|
10
(5) |
11
(3) |
12
(11) |
13
(4) |
14
|
15
(3) |
16
(4) |
|
17
(3) |
18
(6) |
19
|
20
(1) |
21
(9) |
22
(8) |
23
(1) |
|
24
|
25
(2) |
26
(3) |
27
(16) |
28
(17) |
29
(22) |
30
(7) |
|
31
(4) |
|
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2010-01-13 21:03:18
|
> Any idea how to attack the problem? > Any workaround? Don't know, sorry. Obviously if you can reduce it to a test case that is small enough to be debuggable, that would be a big help. J |
|
From: Konstantin S. <kon...@gm...> - 2010-01-13 10:21:54
|
Hi, Memcheck hangs at the very end of some of our programs with ~5% probability. I tried running with --trace-signals=yes --trace-syscalls=yes --time-stamp=yes and here is what I've got: When the program finishes successfully, I see 00:00:00:23.549 -1351-- sigvgkill for lwp 31360 tid 5 00:00:00:23.549 31351-- sigvgkill for lwp 31363 tid 7 00:00:00:23.549 -1351-- sigvgkill for lwp 31360 tid 5 00:00:00:23.549 -1351-- sigvgkill for lwp 31360 tid 5 --> [pre-success] Success(0x0:0x0) --00:00:00:23.551 31351-- Caught __NR_exit; running __libc_freeres() <and the program terminates> When the program hangs, I see --00:00:00:23.987 4983-- sigvgkill for lwp 5193 tid 2 --00:00:00:23.987 4983-- get_thread_out_of_syscall zaps tid 3 lwp 5194 --00:00:00:23.987 4983-- sigvgkill for lwp 5194 tid 3 --00:00:00:23.987 4983-- get_thread_out_of_syscall zaps tid 5 lwp 5196 --00:00:00:23.987 4983-- sigvgkill for lwp 5196 tid 5 --> [pre-success] Success(0x0:0x0) <nothing else is happening, valgrind hangs until it is killed externally by timeout> Which is worse, I can not reproduce this on any machine on which I can attach with gdb... Any idea how to attack the problem? Any workaround? Thanks, --kcc |
|
From: Vince W. <vi...@cs...> - 2010-01-13 02:12:52
|
On Wed, 13 Jan 2010, Danny Robson wrote: > I would be a little concerned about feeding approximate processor > timing values into what I believe is a reasonable precise DRAM timing > model. This is actually the topic of my PhD thesis (defended last month, am finishing up the thesis right now). I look at using DBI tools like Valgrind and Qemu to do architectural simulations, in an attempt to get results faster than "cycle-accurate" simulation with good enough accuracy. It turns out that for a RISC chip, such as MIPS, you can get very good cycle estimations based solely on cache and branch predictor results (even on an out-of-order processor). Unfortunately the results are not as good for x86, and it's even trickier if you are trying to do multi-core. > If you are interested in this level of precision it may be more > appropriate to look at PTLsim[1], which uses a 'cycle-accurate' > processing timing model. It's also at least two orders of magnitude slower, which is why alternate options are usually explored. Vince |
|
From: Danny R. <dr...@cs...> - 2010-01-13 00:59:23
|
On Tue, 12 Jan 2010 13:31:37 +0530 Milind <km...@gm...> wrote: > I have started exploring valgrind recently. I wanted to know if > valgrind core keeps track of the CPU clock ticks. I want to record > memory access pattern of my program. It might help to know more about what you want to accomplish at the end of the day. Do you want to identify regions of suboptimal code, quantify the runtime of some application, experiment with different system parameters? > In that context, I wanted to record the CPU clock tick value at the > time of memory access. I want to feed output of valgrind to DRAMsim > which needs memory addr that is being accessed, access type (read, > write, etc) and the cpu clock time value when the access is being > done. I would be a little concerned about feeding approximate processor timing values into what I believe is a reasonable precise DRAM timing model. If you are interested in this level of precision it may be more appropriate to look at PTLsim[1], which uses a 'cycle-accurate' processing timing model. [1] http://www.ptlsim.org/ -- Danny |