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
(2) |
2
|
3
(1) |
|
4
(3) |
5
(5) |
6
(1) |
7
(3) |
8
(1) |
9
|
10
|
|
11
|
12
|
13
(1) |
14
|
15
|
16
|
17
|
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
|
25
|
26
(5) |
27
(1) |
28
|
29
|
30
|
31
(1) |
|
From: Julian S. <js...@ac...> - 2003-05-05 23:04:10
|
Version 1.9.6 (7 May 2003 or thereabouts) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Major changes in 1.9.6: - Improved threading support for glibc >= 2.3.2 (SuSE 8.2, RedHat 9, to name but two ...) It turned out that 1.9.5 had problems with threading support on glibc >= 2.3.2, usually manifested by threaded programs deadlocking in system calls, or running unbelievably slowly. Hopefully these are fixed now. 1.9.6 is the first valgrind which gives reasonable support for glibc-2.3.2. Also fixed a 2.3.2 problem with pthread_atfork(). - Majorly expanded FAQ.txt. We've added workarounds for all common problems for which a workaround is known. Minor changes in 1.9.6: - Fix identification of the main thread's stack. Incorrect identification of it was causing some on-stack addresses to not get identified as such. This only affected the usefulness of some error messages; the correctness of the checks made is unchanged. - Support for kernels >= 2.5.68. - Dummy implementations of __libc_current_sigrtmin, __libc_current_sigrtmax and __libc_allocate_rtsig, hopefully good enough to keep alive programs which previously died for lack of them. - Fix bug in the VALGRIND_DISCARD_TRANSLATIONS client request. - Fix bug in the DWARF2 debug line info loader, when instructions following each other have source lines far from each other (e.g. with inlined functions). - Debug info reading: read symbols from both "symtab" and "dynsym" sections, rather than merely from the one that comes last in the file. - New syscall support: prctl(), creat(), lookup_dcookie(). - When checking calls to accept(), recvfrom(), getsocketopt(), don't complain if buffer values are NULL. - Try and avoid assertion failures in mash_LD_PRELOAD_and_LD_LIBRARY_PATH. - Minor bug fixes in cg_annotate. |
|
From: Julian S. <js...@ac...> - 2003-05-05 22:13:17
|
Ok, I will merge this, if you think it is correct and tested enough. I was just about to finalise 1.9.6, but I think I can put it in. Except cvs is currently not working :-( J On Monday 05 May 2003 9:04 pm, Josef Weidendorfer wrote: > Hi, > > recently I found that there is sometimes cost attributed to some strange > lines (with cachegrind/calltree) with GCC 3.x (using the DWARF2 debug info > format). > > I had time to look at this. There is a bug in the DWARF2 debug line info > loader when instructions following each other have source lines far from > each other (e.g. with inlined functions). > > Attached is the patch to fix this. > Long time ago I already provided a fix for the DWARF2 debug info loader. > That one introduced "last_address". Obviously I forgot to add variables to > save the last source position, as this patch does now. > > I suppose this should also go into the stable branch... > > Josef |
|
From: Josef W. <Jos...@gm...> - 2003-05-05 21:00:06
|
Hi, recently I found that there is sometimes cost attributed to some strange lines (with cachegrind/calltree) with GCC 3.x (using the DWARF2 debug info format). I had time to look at this. There is a bug in the DWARF2 debug line info loader when instructions following each other have source lines far from each other (e.g. with inlined functions). Attached is the patch to fix this. Long time ago I already provided a fix for the DWARF2 debug info loader. That one introduced "last_address". Obviously I forgot to add variables to save the last source position, as this patch does now. I suppose this should also go into the stable branch... Josef |
|
From: Josef W. <Jos...@gm...> - 2003-05-05 17:39:19
|
Hi Nick, what's needed in cachegrind to support multiple processor caches and coherency protocols among them? I have a wish item here, and perhaps it's quite easy to implement. Motivation: Multithreaded (PThread) programs are handled quite fine with cachegrind, but the results can be misleading because only one cache hierarchy is simulated: If the real program will be run on a 2-processor machine and we have 2 threads, there should be 2 caches (for each processor) simulated. The default configuration could be to simulate as many caches as there are processors in your machine, and use a simple static round robin mapping from threads to the simulated caches. Items I think that have to be done: 1. Reserve some bits from the tag value of each cache entry for state bits of the coherence protocol for this entry (should always be fine because there's no direct-mapped cache with a cacheline-size of 1 byte). 1. allocate multiple "static cache_t2 I1, D1, L2", 2. switch the cache_t2 structures on a thread switch, 3. change cachesim_##L##_doref to handle a cache coherence protocol (E.g. invalidating cache entries of remote caches on writes). Do you think this is doable/useful at all, or am I overlooking something? Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-05-05 13:21:11
|
Hi,
Two things:
1. Up until now, when developing Valgrind, to run it you had to do
"make install" and run it from the installed tree. I just committed to
HEAD a change that allows you to run it from the source directory
without having to install, if you see what I mean. The big advantage
of this is reduced compile times.
2. The regression test suite used to work on my machine but not on anyone
else's. It's now been robustified (further) against
distro/compiler/glibc/etc differences, and should (in theory) work for
anyone. I'd be interested to hear if it doesn't work for you. Note
that the tests:
memcheck/tests/mismatches
memcheck/tests/new_override
currently fail; mismatches is due to a distro/compiler/whatever
problem and should be fixed Real Soon Now, new_override represents a
real bug in Valgrind, and I'm not sure when it will be fixed. The big
advantage of using the tests is they make your life easier -- spotting
problems when you make a change.
See the new file README_DEVELOPERS for instructions on both points.
N
|