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
(6) |
|
2
(6) |
3
(9) |
4
(4) |
5
(1) |
6
|
7
|
8
|
|
9
|
10
(2) |
11
(1) |
12
(2) |
13
(4) |
14
(6) |
15
(8) |
|
16
(9) |
17
(5) |
18
(13) |
19
(6) |
20
(15) |
21
(17) |
22
(19) |
|
23
(2) |
24
(4) |
25
(2) |
26
(10) |
27
(6) |
28
(9) |
29
(3) |
|
30
|
|
|
|
|
|
|
|
From: Paul F. <pj...@wa...> - 2023-04-27 20:02:06
|
On 24/04/2023 23:29, Carl Love via Valgrind-developers wrote: > == 714 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, > 0 stdoutB failures, 2 post failures == > massif/tests/new-cpp (post) > massif/tests/overloaded-new (post) > And these two might be easy to fix if you run the testcase normally and see if you can identify the extra allocating functions and add them to the vgtest files in the --ignore-fn list. E.g., for new-exp there is vgopts: --stacks=no --time-unit=B --massif-out-file=massif.out vgopts: --ignore-fn=__part_load_locale --ignore-fn=__time_load_locale --ignore-fn=dwarf2_unwind_dyld_add_image_hook vgopts: --ignore-fn=get_or_create_key_element --ignore-fn=_GLOBAL__sub_I_eh_alloc.cc --ignore-fn=call_init.part.0 (On FreeBSD I ended up adding a couple of extra expected for when running GCC builds because stripped libstdc++ and no debuginfo package). A+ Paul |
|
From: Bart V. A. <bva...@ac...> - 2023-04-27 17:08:21
|
On 4/26/23 17:06, Nicholas Nethercote wrote: > Auto-formatting is very common these days, to the point of being standard, and blanket opposition to auto-formatting has become a minority position. Really? Can you name one major open source project written in C or C++, that is not controlled by Mozilla and that enforces the formatting of the code by rejecting push requests that do not comply with the code style of that project? Bart. |
|
From: Carl L. <ce...@us...> - 2023-04-27 16:47:56
|
On Thu, 2023-04-27 at 18:29 +0200, Mark Wielaard wrote: > Hi Carl, > > <snip> > > The test failures on Power 10 that I saw on one of the Power 10 > > systems > > was fixed, as expected. > > > > I see the following on both Power 10 systems. > > > > == 714 tests, 2 stderr failures, 0 stdout failures, 0 stderrB > > failures, > > 0 stdoutB failures, 2 post failures == > > memcheck/tests/bug340392 (stderr) > > memcheck/tests/linux/rfcomm (stderr) > > massif/tests/new-cpp (post) > > massif/tests/overloaded-new (post) > > So pretty close to zero fail. > > bug340392 is mentioned as failing for ppc64 in in > https://bugs.kde.org/show_bug.cgi?id=352364 I wonder if we can mark > it > known-fail/ignore with a reference to that bug? I read thru the bugzilla. I have never delved into this bug. From the sounds, this is very PPC specific. The effort to make this comparison highly accurate is not trivial. The bug has been around for 8 years and other than this test, no one seems to have needed the really high level of accuracy in the comparison. So, yea, I would be fine as marking this as a known fail and reference the bug. Carl |
|
From: Mark W. <ma...@kl...> - 2023-04-27 16:29:39
|
Hi Carl,
On Mon, Apr 24, 2023 at 02:29:13PM -0700, Carl Love wrote:
> Mark:
>
> Thanks for the pointer on IRC chat to the RC2 tarball. I must have
> missed the email.
>
> I noticed the following message on a Power 10 system.
>
> ./autogen.sh
> running: aclocal
> running: autoheader
> running: automake -a
> Unescaped left brace in regex is passed through in regex; marked by <--
> HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /home/carll/bin/automake
> line 3936.
> running: autoconf
>
> The autoconf version is:
>
> autoconf --version
> autoconf (GNU Autoconf) 2.69
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+/Autoconf: GNU GPL version 3 or later
>
> Note the autoconf seemed to work ok. I was still able to configure and
> build Valgrind and run the testsuite.
It is actually automake that produces the warning. But it is indeed
harmless. It is produced by a newer perl (>= 5.21.1) used with an
older automake (< 1.15.1).
> The test failures on Power 10 that I saw on one of the Power 10 systems
> was fixed, as expected.
>
> I see the following on both Power 10 systems.
>
> == 714 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures,
> 0 stdoutB failures, 2 post failures ==
> memcheck/tests/bug340392 (stderr)
> memcheck/tests/linux/rfcomm (stderr)
> massif/tests/new-cpp (post)
> massif/tests/overloaded-new (post)
So pretty close to zero fail.
bug340392 is mentioned as failing for ppc64 in in
https://bugs.kde.org/show_bug.cgi?id=352364 I wonder if we can mark it
known-fail/ignore with a reference to that bug?
I cannot easily test rfcomm my self since I don't seem to have
bluetooth enabled on my powerpc setup.
new-cpp/overload-new (post) checks are very dependent on the version
of libstdc++ installed. I don't know how to make these tests less
fragile.
Cheers,
Mark
|
|
From: Paul F. <pa...@so...> - 2023-04-27 07:30:57
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=be26a1773eeea9199911600135e22e5f0d0a3541 commit be26a1773eeea9199911600135e22e5f0d0a3541 Author: Paul Floyd <pj...@wa...> Date: Thu Apr 27 09:19:46 2023 +0200 dhat: remove initial count value from access count histogram user requests Based on feedback from Nick Nethercote. Diff: --- NEWS | 3 +-- dhat/dh_main.c | 12 +++--------- dhat/dhat.h | 18 +++--------------- dhat/docs/dh-manual.xml | 20 +++++++++----------- dhat/tests/user_histo1.cpp | 8 ++++---- 5 files changed, 20 insertions(+), 41 deletions(-) diff --git a/NEWS b/NEWS index d9e04ab823..22d5d4a1d8 100644 --- a/NEWS +++ b/NEWS @@ -135,8 +135,7 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. * DHAT: - A new kind of user request has been added which allows you to override the 1024 byte limit on access count histograms for blocks - of memories. Two client requests are available, - DHAT_HISTOGRAM_MEMORY_UNINIT and DHAT_HISTOGRAM_MEMORY_INIT. + of memory. The client request is DHAT_HISTOGRAM_MEMORY. * ==================== FIXED BUGS ==================== diff --git a/dhat/dh_main.c b/dhat/dh_main.c index ac0a7478e9..24d1c2768b 100644 --- a/dhat/dh_main.c +++ b/dhat/dh_main.c @@ -1232,7 +1232,6 @@ static Bool dh_handle_client_request(ThreadId tid, UWord* arg, UWord* ret) case VG_USERREQ__DHAT_HISTOGRAM_MEMORY: { Addr address = (Addr)arg[1]; - UWord initial_count = arg[2]; Block* bk = find_Block_containing( address ); // bogus address @@ -1254,7 +1253,7 @@ static Bool dh_handle_client_request(ThreadId tid, UWord* arg, UWord* ret) return False; } - // already histogrammed + // too big if (bk->req_szB > USER_HISTOGRAM_SIZE_LIMIT) { VG_(message)( Vg_UserMsg, @@ -1266,13 +1265,8 @@ static Bool dh_handle_client_request(ThreadId tid, UWord* arg, UWord* ret) bk->histoW = VG_(malloc)("dh.new_block.3", bk->req_szB * sizeof(UShort)); - if (initial_count == 0U) { - VG_(memset)(bk->histoW, 0, bk->req_szB * sizeof(UShort)); - } else { - for (SizeT i = 0U; i < bk->req_szB; ++i) { - bk->histoW[i] = 1U; - } - } + VG_(memset)(bk->histoW, 0, bk->req_szB * sizeof(UShort)); + return True; } diff --git a/dhat/dhat.h b/dhat/dhat.h index cbedbe88b6..97e1ade8fc 100644 --- a/dhat/dhat.h +++ b/dhat/dhat.h @@ -65,7 +65,6 @@ typedef enum { VG_USERREQ__DHAT_AD_HOC_EVENT = VG_USERREQ_TOOL_BASE('D', 'H'), VG_USERREQ__DHAT_HISTOGRAM_MEMORY, - VG_USERREQ__DHAT_HISTOGRAM_ARRAY, // This is just for DHAT's internal use. Don't use it. _VG_USERREQ__DHAT_COPY = VG_USERREQ_TOOL_BASE('D','H') + 256 @@ -78,21 +77,10 @@ typedef VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__DHAT_AD_HOC_EVENT, \ (_qzz_weight), 0, 0, 0, 0) -// for limited histograms of memory larger than 1k -#define DHAT_HISTOGRAM_MEMORY(_qzz_address, _qzz_initial_count) \ +// for access count histograms of memory larger than 1k +#define DHAT_HISTOGRAM_MEMORY(_qzz_address) \ VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__DHAT_HISTOGRAM_MEMORY, \ - (_qzz_address), (_qzz_initial_count), 0, 0, 0) - -// convenience macro for DHAT_HISTOGRAM_MEMORY -// for initialized memory (calloc, std::vector with initialization) -#define DHAT_HISTOGRAM_MEMORY_INIT(_qzz_address) \ - DHAT_HISTOGRAM_MEMORY(_qzz_address, 1U) - -// convenience macro for DHAT_HISTOGRAM_MEMORY -// for uninitialized memory (malloc, std::vector without initialization) -#define DHAT_HISTOGRAM_MEMORY_UNINIT(_qzz_address) \ - DHAT_HISTOGRAM_MEMORY(_qzz_address, 0U) - + (_qzz_address), 0, 0, 0, 0) #endif diff --git a/dhat/docs/dh-manual.xml b/dhat/docs/dh-manual.xml index 9d99b4f352..8f30ff7f7e 100644 --- a/dhat/docs/dh-manual.xml +++ b/dhat/docs/dh-manual.xml @@ -427,24 +427,22 @@ to 1024 bytes. This is done to limit the performance overhead and also to keep the size of the generated output reasonable. However, it is possible to override this limit using client requests. The use-case for this is to first run DHAT normally, and then identify any large blocks that you would like to further -investigate with access histograms. The client requests are declared in -<filename>dhat/dhat.h</filename>. There are two versions, <computeroutput>DHAT_HISTOGRAM_MEMORY_INIT</computeroutput> and -<computeroutput>DHAT_HISTOGRAM_MEMORY_UNINIT</computeroutput>. The -UNINIT version should be used with allocators that return uninitialized -memory (like <computeroutput>malloc</computeroutput> and <computeroutput>new</computeroutput> -without a constructor). The INIT version should be used with allocators -that initialize memory (like <computeroutput>calloc</computeroutput> and <computeroutput>new</computeroutput> -with a constructor). The macros should be placed immediately after the -call to the allocator, and use the pointer returned by the allocator.</para> +investigate with access count histograms. The client request is declared in +<filename>dhat/dhat.h</filename> and is called <computeroutput>DHAT_HISTOGRAM_MEMORY</computeroutput>. +The macro should be placed immediately after the call to the allocator, +and use the pointer returned by the allocator.</para> <programlisting><![CDATA[ // LargeStruct bigger than 1024 bytes struct LargeStruct* ls = malloc(sizeof(struct LargeStruct)); -DHAT_HISTOGRAM_MEMORY_INIT(ls); +DHAT_HISTOGRAM_MEMORY(ls); ]]></programlisting> <para>The memory that can be profiled in this way with user requests -has a further upper limit of 25kbytes.</para> +has a further upper limit of 25kbytes. Be aware that the access counts +will all be set to zero. This means that the access counts will not +include any reads or writes performed during initialisation. An example where this +will happen are uses of C++ <computeroutput>new</computeroutput> with user-defined constructors.</para> <para>Access counts can be useful for identifying data alignment holes or other layout inefficiencies.</para> diff --git a/dhat/tests/user_histo1.cpp b/dhat/tests/user_histo1.cpp index f5c8e69bbc..191fde2c5a 100644 --- a/dhat/tests/user_histo1.cpp +++ b/dhat/tests/user_histo1.cpp @@ -7,7 +7,7 @@ int main() { std::vector<uint8_t> vec(2000, 0); - DHAT_HISTOGRAM_MEMORY_INIT(vec.data()); + DHAT_HISTOGRAM_MEMORY(vec.data()); std::mt19937 gen(42);; std::uniform_int_distribution<> index_distrib(0, 1999); std::uniform_int_distribution<> val_distrib(0, 255); @@ -23,12 +23,12 @@ int main() // try to generate some warnings vec.resize(500); vec.shrink_to_fit(); - DHAT_HISTOGRAM_MEMORY_UNINIT(vec.data()); + DHAT_HISTOGRAM_MEMORY(vec.data()); auto old = vec.data(); vec.resize(100000); // old should have been deleted - DHAT_HISTOGRAM_MEMORY_UNINIT(old); + DHAT_HISTOGRAM_MEMORY(old); // and this is too big - DHAT_HISTOGRAM_MEMORY_UNINIT(vec.data()); + DHAT_HISTOGRAM_MEMORY(vec.data()); } |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-27 00:06:25
|
On Thu, 27 Apr 2023 at 00:04, Bart Van Assche <bva...@ac...> wrote: > Are these the only disadvantages of reformatting the entire code base? I > see more disadvantages: > > - Preserving the formatting of code that is in tabular format requires > manual annotation (/* clang-format off */ and /* clang-format on */). Who > will do the tedious work of reviewing the entire code base and annotating > all the code for which formatting should be preserved? > > I'm happy to start. I think doing the work in chunks makes sense, e.g. one subdirectory at a time, something like that. After that, others can contribute if they like. A prerequisite for that is deciding what rules to put in the .clang-format file. I am also happy to work on that. Some discussion, along with example diffs, will be necessary. > > - It is a certainty that reformatting the code with clang-format will > make formatting worse for a significant fraction of the code base. A > summary of the formatting made worse by clang-format for one particular > Linux kernel source file is available here: *Re: [PATCH] scsi: > megaraid: cleanup formatting of megaraid > <https://lore.kernel.org/linux-scsi/CAKwvOdnWHVV+3s8SO=Q8F...@ma.../>* > . > > That's a handful of quibbles. There will always be places where an auto-formatter does something that somebody doesn't like. That is also true when humans format code. > > - It is likely that the Valgrind .clang-format file will be modified > in the future. The Linux kernel .clang-format style file was introduced in > 2018 and since then has been modified 44 times: > > $ git log .clang-format | grep -c ^commit > 45 > > Will the entire Valgrind code base be reformatted every time the > Valgrind .clang-format file is modified? > > I expect .clang-format changes to be rare and minimal, and some care will be needed when deciding what rules to put in the initial .clang-format file. Changing the indent size every six months would be silly, of course. But to answer the question: absolutely. Because the goal here is to make auto-formatting mandatory. Any code that isn't formatted properly would be rejected. So if the style changes, the code changes with it. (Mandatory pre-commit testing, another modern software development convenience that Valgrind currently lacks, would help with this.) As for the Linux example: the "modified 44 times" is highly misleading. The version history of the file can be seen here <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/.clang-format>. The file currently has 688 lines, but 81% of those lines are for macros listed in the `ForEachMacros <https://clang.llvm.org/docs/ClangFormatStyleOptions.html#foreachmacros>` rule, which is a list of macros that needs particular treatment. Most of the 44 modifications are just modifications of that list, which are trivial and won't affect any code other than those macros, and aren't relevant for Valgrind. There were only five commits with meaningful changes that didn't involve that list: one, <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/.clang-format?id=c90f3b8c4b5b7ff3ee7103640a2ab1c960c69645> two <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/.clang-format?id=c90f3b8c4b5b7ff3ee7103640a2ab1c960c69645>, three <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/.clang-format?id=96232c7d4f847a5e597177236159e6b32ccf60e4>, four <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/.clang-format?id=d7f6604341c748f803810664d5603af22b84a8cc>, five <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/.clang-format?id=781121a7f6d11d7cae44982f174ea82adeec7db0>. Only one of those (the third one) changes more than one rule, and that was part of the upgrade from clang-format 4 to 6. clang-format is more mature now so changes of that sort are less likely to be needed in the future. > > > Is the above list complete? Did I perhaps overlook any disadvantages? > Auto-formatting is very common these days, to the point of being standard, and blanket opposition to auto-formatting has become a minority position. Which makes sense, because many projects have style guides, and automatic enforcement of style is better than manual enforcement, being less work and more reliable. Valgrind's development processes need to move with the times. Nick |