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
(32) |
Oct
|
Nov
|
Dec
|
|
From: Mark W. <ma...@so...> - 2023-04-28 16:04:56
|
The signed tag 'VALGRIND_3_21_0' was created pointing to:
d97fed7c3e... -> 3.21.0 final
Tagger: Mark Wielaard <ma...@kl...>
Date: Fri Apr 28 18:04:18 2023 +0200
valgrind 3.21.0 release
|
|
From: Mark W. <ma...@so...> - 2023-04-28 15:52:52
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=071742f11b8966d6eb4f06d7a14693cb07efe64f commit 071742f11b8966d6eb4f06d7a14693cb07efe64f Author: Mark Wielaard <ma...@kl...> Date: Fri Apr 28 17:27:35 2023 +0200 Add bug 469049 (--enable-lto=yes) to known issues Diff: --- NEWS | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/NEWS b/NEWS index 118c5e65d0..510f21fc2a 100644 --- a/NEWS +++ b/NEWS @@ -195,6 +195,11 @@ To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed above. +* ==================== KNOWN ISSUES =================== + +* configure --enable-lto=yes is know to not work in all setups. + See bug 469049. Workaround: Build without LTO. + (3.21.0.RC1: 14 Apr 2023) (3.21.0.RC2: 21 Apr 2023) |
|
From: Mark W. <ma...@so...> - 2023-04-28 15:52:51
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=d97fed7c3e4aa7c910dfa0b6c5de12fd6cf08155 commit d97fed7c3e4aa7c910dfa0b6c5de12fd6cf08155 Author: Mark Wielaard <ma...@kl...> Date: Fri Apr 28 17:30:04 2023 +0200 -> 3.21.0 final Diff: --- NEWS | 2 +- configure.ac | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 510f21fc2a..342a733650 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,4 @@ -Release 3.21.0 (?? Apr 2023) +Release 3.21.0 (28 Apr 2023) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, diff --git a/configure.ac b/configure.ac index d1af9de0d3..79b17f3940 100755 --- a/configure.ac +++ b/configure.ac @@ -17,8 +17,8 @@ m4_define([v_major_ver], [3]) m4_define([v_minor_ver], [21]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], [RC2]) -m4_define([v_rel_date], ["21 Apr 2023"]) +m4_define([v_suffix_ver], []) +m4_define([v_rel_date], ["28 Apr 2023"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], |
|
From: Mark W. <ma...@so...> - 2023-04-28 13:11:17
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=b4ec6a6ff767098714ffa8c4e3e3081d98fd2d66 commit b4ec6a6ff767098714ffa8c4e3e3081d98fd2d66 Author: Mark Wielaard <ma...@kl...> Date: Fri Apr 28 13:34:48 2023 +0200 Support SCV_FLAG also on VGP_ppc64be_linux Running on a kernel that supports the SCV instruction (sets PPC_FEATURE2_SCV in auxv AT_HWCAPS2) valgrind will assert: valgrind: m_syswrap/syswrap-main.c:549 (getSyscallArgsFromGuestState): Assertion 'gst->guest_syscall_flag == SC_FLAG' failed. Removing that assert makes most things work. But also filter out PPC_FEATURE2_SCV from AT_HWCAPS2 for the client, so it shouldn't try using the SCV instruction. https://bugs.kde.org/show_bug.cgi?id=469097 Diff: --- NEWS | 1 + coregrind/m_initimg/initimg-linux.c | 4 ++++ coregrind/m_syswrap/syswrap-main.c | 5 ----- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 22d5d4a1d8..118c5e65d0 100644 --- a/NEWS +++ b/NEWS @@ -188,6 +188,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 468401 [PATCH] Add a style file for clang-format 468556 Build failure for vgdb 468606 build: remove "Valgrind relies on GCC" check/output +469097 ppc64(be) doesn't support SCV syscall instruction n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than VG_(unimplemented) To see details of a given bug, visit diff --git a/coregrind/m_initimg/initimg-linux.c b/coregrind/m_initimg/initimg-linux.c index 4da9a8b976..7a7d453350 100644 --- a/coregrind/m_initimg/initimg-linux.c +++ b/coregrind/m_initimg/initimg-linux.c @@ -852,7 +852,11 @@ Addr setup_client_stack( void* init_sp, | 0x04000000ULL /* TAR */ | 0x04000000ULL /* VEC_CRYPTO */ | 0x00800000ULL /* ARCH_3_00 */ +#if defined(VGP_ppc64le_linux) + /* Should also be supported on ppc64be, + but see https://bugs.kde.org/show_bug.cgi?id=469097 */ | 0x00100000ULL /* PPC_FEATURE2_SCV */ +#endif | 0x00400000ULL /* HAS_IEEE128 */ | 0x00200000ULL /* PPC_FEATURE2_DARN */ | 0x00040000ULL /* ARCH_3_1 */ diff --git a/coregrind/m_syswrap/syswrap-main.c b/coregrind/m_syswrap/syswrap-main.c index abd8472e92..4f8c0fe1cb 100644 --- a/coregrind/m_syswrap/syswrap-main.c +++ b/coregrind/m_syswrap/syswrap-main.c @@ -544,11 +544,6 @@ void getSyscallArgsFromGuestState ( /*OUT*/SyscallArgs* canonical, canonical->arg7 = gst->guest_syscall_flag; canonical->arg8 = 0; -#if defined(VGP_ppc64be_linux) - /* The sc instruction is currently only supported on LE systems. */ - vg_assert(gst->guest_syscall_flag == SC_FLAG); -#endif - #elif defined(VGP_x86_freebsd) VexGuestX86State* gst = (VexGuestX86State*)gst_vanilla; UWord *stack = (UWord *)gst->guest_ESP; |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-28 06:08:27
|
On Fri, 28 Apr 2023 at 03:08, Bart Van Assche <bva...@ac...> wrote: > > 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? > MongoDB <https://github.com/mongodb/mongo/wiki/Server-Code-Style>, Blender <https://wiki.blender.org/wiki/Tools/ClangFormat>, Godot <https://docs.godotengine.org/en/stable/contributing/development/code_style_guidelines.html> all mandate the use of clang-format. (I didn't check whether they enforce this with a pre-push check, but the language in the linked documents makes it clear that auto-formatting is mandatory.) There's no good reason to ignore other languages, though. I know for certain that mandatory autoformatting is ubiquitous in Rust projects, with rustc and Cargo being obvious examples. I suspect there are countless Go and Swift projects that use it too. Nick |
|
From: Nicholas N. <nj...@so...> - 2023-04-28 00:31:27
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=d061b81f402f92df63a9843743259cd7fb68e477 commit d061b81f402f92df63a9843743259cd7fb68e477 Author: Nicholas Nethercote <n.n...@gm...> Date: Fri Apr 28 10:28:30 2023 +1000 Only do git configuration if in a git repo. Diff: --- autogen.sh | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/autogen.sh b/autogen.sh index 27f54f7d62..611bb14618 100755 --- a/autogen.sh +++ b/autogen.sh @@ -16,6 +16,10 @@ run autoheader run automake -a run autoconf -# Valgrind-specific Git configuration. -echo "running: git configuration" -git config blame.ignoreRevsFile .git-blame-ignore-revs +# Valgrind-specific Git configuration, if appropriate. +if git rev-parse --is-inside-work-tree > /dev/null 2>&1 ; then + echo "running: git configuration" + git config blame.ignoreRevsFile .git-blame-ignore-revs +else + echo "skipping: git configuration" +fi |
|
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 |
|
From: Paul F. <pa...@so...> - 2023-04-26 20:18:14
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=11af86679796f1c099ae5f65a804b67018afaf32 commit 11af86679796f1c099ae5f65a804b67018afaf32 Author: Paul Floyd <pj...@wa...> Date: Wed Apr 26 22:17:16 2023 +0200 FreeBSD: add libc suppressions for Helgrind and DRD Diff: --- freebsd-drd.supp | 54 +++++++++++++++++++++++++++++++++++++++++-- freebsd-helgrind.supp | 64 +++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 109 insertions(+), 9 deletions(-) diff --git a/freebsd-drd.supp b/freebsd-drd.supp index 2248389587..93ad79f4bd 100644 --- a/freebsd-drd.supp +++ b/freebsd-drd.supp @@ -31,7 +31,7 @@ { DRD-MANY1 drd:ConflictingAccess - obj:/lib/libthr.so.3 + obj:*/lib*/libthr.so.3 obj:/libexec/ld-elf*.so.1 } { @@ -52,7 +52,7 @@ { DRD-MANY4 drd:ConflictingAccess - obj:/lib/libthr.so.3 + obj:*/lib*/libthr.so.3 } { DRD-UNWIND1 @@ -190,3 +190,53 @@ drd:ConflictingAccess fun:_ZL11* } +{ + DRD-FREEBSD131-FOPEN1 + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + fun:fopen +} +{ + DRD-FREEBSD131-FOPEN2 + drd:ConflictingAccess + fun:fopen + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-FGETS + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + ... + fun:fgets +} +{ + DRD-FREEBSD131-FCLOSE + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + fun:fclose +} +{ + DRD-FREEBSD131-RES-VINIT + drd:ConflictingAccess + fun:__h_errno_set + fun:__res_vinit + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-ERRNO-SET + drd:ConflictingAccess + fun:__h_errno_set + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-LOCALECONV + drd:ConflictingAccess + fun:localeconv_l + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-VSPRINTF + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + fun:vsprintf +} diff --git a/freebsd-helgrind.supp b/freebsd-helgrind.supp index 32af0a7626..be10339c62 100644 --- a/freebsd-helgrind.supp +++ b/freebsd-helgrind.supp @@ -3,7 +3,7 @@ { HELGRIND-LIBTHR1 Helgrind:Race - obj:*/lib*/libthr.so.3* + obj:*/lib*/libthr.so.3 } { HELGRIND-LIB-RTLD1 @@ -99,7 +99,7 @@ HELGRIND-PTHREAD-SELF1 Helgrind:Race fun:mythread_wrapper - obj:*/lib*/libthr.so.3* + obj:*/lib*/libthr.so.3 } { HELGRIND-SEM-CLOCKWAIT1 @@ -145,11 +145,11 @@ { HELGRIND-CXX-UNWIND Helgrind:Race - obj:/lib/libcxxrt.so.1 - obj:/lib/libthr.so.3 - obj:/lib/libthr.so.3 - obj:/lib/libthr.so.3 - obj:/lib/libgcc_s.so.1 + obj:*/lib*/libcxxrt.so.1 + obj:*/lib*/libthr.so.3 + obj:*/lib*/libthr.so.3 + obj:*/lib*/libthr.so.3 + obj:*/lib*/libgcc_s.so.1 fun:_Unwind_ForcedUnwind } { @@ -167,3 +167,53 @@ Helgrind:Race fun:_ZNSt3__119__thread_local_dataEv } +{ + HELGRIND-LIBC-FOPEN1 + Helgrind:Race + obj:*/lib*/libc.so.7 + fun:fopen +} +{ + HELGRIND-LIBC-FOPEN2 + Helgrind:Race + fun:fopen + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-FGETS + Helgrind:Race + obj:*/lib*/libc.so.7 + ... + fun:fgets +} +{ + HELGRIND-LIBC-FCLOSE + Helgrind:Race + obj:*/lib*/libc.so.7 + fun:fclose +} +{ + HELGRIND-LIBC-RES-STATE + Helgrind:Race + fun:__res_state + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-ERRNO-SET + Helgrind:Race + fun:__h_errno_set + ... + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-LOCALECONV-L + Helgrind:Race + fun:localeconv_l + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-VSPRINTF + Helgrind:Race + obj:*/lib*/libc.so.7 + fun:vsprintf +} |
|
From: Mark W. <ma...@kl...> - 2023-04-26 19:37:31
|
Hi, On Wed, 2023-04-26 at 13:41 +0200, Paul Floyd wrote: > On 25-04-23 17:28, Alexandra Hájková wrote: > > when waiting for valgrind to start. > > Would you like this to go in before 3.21 ships? This would be nice to get in before the release because it makes the vgdb --wait argument work correctly for --multi mode. I double checked the patch and it looks good to me. So pushed. Thanks, Mark |
|
From: Mark W. <ma...@so...> - 2023-04-26 19:37:18
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=476d036084139e5a070d016d0799b552c5431ac0 commit 476d036084139e5a070d016d0799b552c5431ac0 Author: Alexandra Hájková <aha...@re...> Date: Tue Apr 25 17:28:52 2023 +0200 vgdb: Use --wait argument in multi mode when waiting for valgrind to start. Diff: --- coregrind/vgdb.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index 21e67c65b7..8ec4240770 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -178,14 +178,20 @@ void add_written(int nrw) static int shared_mem_fd = -1; static -void map_vgdbshared(char* shared_mem) +void map_vgdbshared(char* shared_mem, int check_trials) { struct stat fdstat; void **s; int tries = 50; int err; - /* valgrind might still be starting up, give it 5 seconds. */ + /* valgrind might still be starting up, give it 5 seconds by + * default, or check_trails seconds if it is set by --wait + * to more than a second. */ + if (check_trials > 1) { + DEBUG(1, "check_trials %d\n", check_trials); + tries = check_trials * 10; + } do { shared_mem_fd = open(shared_mem, O_RDWR | O_CLOEXEC); err = errno; @@ -581,7 +587,7 @@ void wait_for_gdb_connect(int in_port) /* prepares the FIFOs filenames, map the shared memory. */ static -void prepare_fifos_and_shared_mem(int pid) +void prepare_fifos_and_shared_mem(int pid, int check_trials) { const HChar *user, *host; unsigned len; @@ -610,7 +616,7 @@ void prepare_fifos_and_shared_mem(int pid) DEBUG(1, "vgdb: using %s %s %s\n", from_gdb_to_pid, to_gdb_from_pid, shared_mem); - map_vgdbshared(shared_mem); + map_vgdbshared(shared_mem, check_trials); } static void @@ -1303,7 +1309,7 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir, /* Do multi stuff. */ static -void do_multi_mode(void) +void do_multi_mode(int check_trials) { char *buf = vmalloc(PBUFSIZ+1); char *q_buf = vmalloc(PBUFSIZ+1); //save the qSupported packet sent by gdb @@ -1458,7 +1464,7 @@ void do_multi_mode(void) if (res == 0) { // Lets report we Stopped with SIGTRAP (05). send_packet ("S05", noackmode); - prepare_fifos_and_shared_mem(valgrind_pid); + prepare_fifos_and_shared_mem(valgrind_pid, check_trials); DEBUG(1, "from_gdb_to_pid %s, to_gdb_from_pid %s\n", from_gdb_to_pid, to_gdb_from_pid); // gdb_relay is an endless loop till valgrind quits. @@ -2392,7 +2398,8 @@ int main(int argc, char** argv) if (!multi_mode) { pid = search_arg_pid(arg_pid, check_trials, show_list); - prepare_fifos_and_shared_mem(pid); + /* We pass 1 for check_trails here, because search_arg_pid already waited. */ + prepare_fifos_and_shared_mem(pid, 1); } else { pid = 0; } @@ -2413,7 +2420,9 @@ int main(int argc, char** argv) } if (multi_mode) { - do_multi_mode (); + /* check_trails is the --wait argument in seconds, defaulting to 1 + * if not given. */ + do_multi_mode (check_trials); } else if (last_command >= 0) { standalone_send_commands(pid, last_command, commands); } else { |
|
From: Mark W. <ma...@so...> - 2023-04-26 19:37:14
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f83f269dd15d7c006ff6b1ecb562f8bd53560a5c commit f83f269dd15d7c006ff6b1ecb562f8bd53560a5c Author: Mark Wielaard <ma...@kl...> Date: Wed Apr 26 21:31:13 2023 +0200 Fix typos in NEWS and valgrind-monitor-def.py NEWS: who_point_at -> who_points_at valgrind-monitor-def.py: MEN -> LEN Diff: --- NEWS | 2 +- coregrind/m_gdbserver/valgrind-monitor-def.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 7974f0c2e9..d9e04ab823 100644 --- a/NEWS +++ b/NEWS @@ -26,7 +26,7 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. to pass it to a subsequent monitor command, the GDB front end command will evaluate the address argument. It is for example possible to do: - (gdb) memcheck who_point_at &some_struct sizeof(some_struct) + (gdb) memcheck who_points_at &some_struct sizeof(some_struct) instead of: (gdb) p &some_struct $2 = (some_struct_type *) 0x1130a0 <some_struct> diff --git a/coregrind/m_gdbserver/valgrind-monitor-def.py b/coregrind/m_gdbserver/valgrind-monitor-def.py index da617cb850..b4e7b992dc 100644 --- a/coregrind/m_gdbserver/valgrind-monitor-def.py +++ b/coregrind/m_gdbserver/valgrind-monitor-def.py @@ -717,7 +717,7 @@ where HEUR is one of: @Vinit("memcheck", "who_points_at", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) class Memcheck_Who_Points_At_Command(Valgrind_ADDR_LEN_opt): """Show places pointing inside LEN (default 1) bytes at ADDR. -Usage: memcheck who_points_at ADDR [MEN] +Usage: memcheck who_points_at ADDR [LEN] With LEN 1, only shows "start pointers" pointing exactly to ADDR. With LEN > 1, will also show "interior pointers" ADDR is an address expression evaluated by GDB. |
|
From: Bart V. A. <bva...@ac...> - 2023-04-26 14:04:45
|
On 4/26/23 03:32, Nicholas Nethercote wrote:
> As I understand it, there are two main objections to mass-reformatting.
>
> * It breaks `git blame`. But as we've seen, this is entirely fixable.
> * "If it ain't broken, don't fix it." But I argue that it the
> current inconsistent formatting is a form of brokenness. Of course
> some care is required to fix it, e.g. the particular style should
> be chosen with care, and diffs should be reviewed by humans and
> not just blindly accepted. But there are high-quality, widely-used
> tools that make it straightforward. We should use them.
>
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?
* 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.../>/.
* 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?
Is the above list complete? Did I perhaps overlook any disadvantages?
Bart.
|
|
From: Paul F. <pj...@wa...> - 2023-04-26 11:58:14
|
On 26-04-23 12:32, Nicholas Nethercote wrote: > > > As I understand it, there are two main objections to mass-reformatting. > > * It breaks `git blame`. But as we've seen, this is entirely fixable. > * "If it ain't broken, don't fix it." But I argue that it the current > inconsistent formatting is a form of brokenness. Of course some care > is required to fix it, e.g. the particular style should be chosen > with care, and diffs should be reviewed by humans and not just > blindly accepted. But there are high-quality, widely-used tools that > make it straightforward. We should use them. Hi Nick I'm much more in favour if the git blame history is maintained. Wrong indentation can be a source of errors. I haven't seen any in the Valgrind source, but more often these days I see "python++" code (C or C++ code that looks like Python). This is the one place where you need to be careful reviewing the diffs. (clang-tidy nags about this as well). A+ Paul |
|
From: Paul F. <pj...@wa...> - 2023-04-26 11:41:23
|
On 25-04-23 17:28, Alexandra Hájková wrote: > when waiting for valgrind to start. Hi Alexandra Would you like this to go in before 3.21 ships? A+ Paul |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-26 10:32:26
|
On Sun, 23 Apr 2023 at 03:44, Mark Wielaard <ma...@kl...> wrote: > > But why do you want to reformat all the existing code? > Isn't it enough if people have easy tools to format new hunks? > > I am happy if we encourage people to use code formatters for > new/changed code. But forcing a reformat of the whole project on > people seems like a bad idea. > > I think Paul's recent accident with clang-format shows why it is not a > good idea to try to reformat any existing code. It just introduces > huge arbitrary changes. > They are not arbitrary changes, they are improvements. Auto-formatting the whole codebase has some major advantages. - Simplicity. "Format all C code with clang-format" is simpler than "Format new C code with clang-format, but leave old C code alone." And partial application can lead to weird results when you make a change that results in a tight interleaving of changed and unchanged lines. - Consistency. Instead of a mishmash of styles, everything is consistent. `foo ( bar )` vs `foo(bar)` is one prime example of an existing inconsistency, with both versions appearing all over the place. It makes me grumpy. - Readability. A lot of the current style choices are just bad. Some of the worst problems can't be fixed in a piecemeal fashion, e.g. three space indents are weird and terrible. There are some implicit principles that inform my opinions here. - The latest revision of the code is the most important revision. This means it's worth making changes to improve things. - Developer experience is important. Code should be enjoyable to work on. There are many aspects to this, and code formatting is one of them. "It's always been like this" is a weak justification for many things. As I understand it, there are two main objections to mass-reformatting. - It breaks `git blame`. But as we've seen, this is entirely fixable. - "If it ain't broken, don't fix it." But I argue that it the current inconsistent formatting is a form of brokenness. Of course some care is required to fix it, e.g. the particular style should be chosen with care, and diffs should be reviewed by humans and not just blindly accepted. But there are high-quality, widely-used tools that make it straightforward. We should use them. Nick |
|
From: Nicholas N. <nj...@so...> - 2023-04-26 07:00:58
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=15313a558081755a783dcf2e3db0e155b3b4fbd2 commit 15313a558081755a783dcf2e3db0e155b3b4fbd2 Author: Nicholas Nethercote <n.n...@gm...> Date: Wed Apr 26 17:00:32 2023 +1000 Clarify try push instructions. Diff: --- README_DEVELOPERS | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/README_DEVELOPERS b/README_DEVELOPERS index 979ee13b4a..5b93b1c870 100644 --- a/README_DEVELOPERS +++ b/README_DEVELOPERS @@ -87,26 +87,21 @@ To get commit access to the valgrind git repository on sourceware you will have to ask an existing developer and fill in the following form: https://sourceware.org/cgi-bin/pdw/ps_form.cgi -Every developer with commit access can use try branches. Code committed -to a try branch will be build by the buildbot at builder.sourceware.org -https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try +Every developer with commit access can use try branches. If you want to try a +branch before pushing you can push to a special named try branch as follows: -If you want to try a commit you can push to a special named try branch -(users/<your-user-name>/try-<your-branch>) as follows: + git push origin $BRANCH:users/$USERNAME/try-$BRANCH - git checkout -b <your-branch> - ...hack, hack, hack... OK, looks good to submit - git commit -a -m "Awesome hack" - git push origin <your-branch>:users/<your-user-name>/try-<your-branch> +Where $BRANCH is the branch name and $USERNAME is your user name. -When all builders have build your patch the buildbot will sent you (or -actually the patch author) an email telling you if any builds failed and -references to all the logs. You can also find the logs and the builds here: +You can see the status of the builders here: https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try +The buildbot will also sent the patch author multiple success/failure emails. + Afterwards you can delete the branch again: - git push origin :users/username/try-<your-branch> + git push origin :users/$USERNAME/try-$BRANCH Debugging Valgrind with GDB |
|
From: Nicholas N. <nj...@so...> - 2023-04-26 06:54:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=ca5486d60ca49420749ff02cf241e0be4b206351 commit ca5486d60ca49420749ff02cf241e0be4b206351 Author: Nicholas Nethercote <n.n...@gm...> Date: Wed Apr 26 16:11:26 2023 +1000 Add a .git-blame-ignore-revs file. This prevents large-scale changes (e.g. auto-formatting) from negatively affecting `git blame`. Diff: --- .git-blame-ignore-revs | 5 +++++ autogen.sh | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs new file mode 100644 index 0000000000..d0d7ea1a1b --- /dev/null +++ b/.git-blame-ignore-revs @@ -0,0 +1,5 @@ +# 2023-04-22: clang-format was run accidentally on a few files. +bf347551c99313a4af9c38bdeda9b946c9795945 + +# 2023-04-22: Revert bf347551c99313a4af9c38bdeda9b946c9795945. +76d6b4591a5a05e43e1a819bf630c0d8ee857a7e diff --git a/autogen.sh b/autogen.sh index 117462c7ff..27f54f7d62 100755 --- a/autogen.sh +++ b/autogen.sh @@ -15,3 +15,7 @@ run aclocal run autoheader run automake -a run autoconf + +# Valgrind-specific Git configuration. +echo "running: git configuration" +git config blame.ignoreRevsFile .git-blame-ignore-revs |
|
From: Alexandra H. <aha...@re...> - 2023-04-25 15:29:08
|
when waiting for valgrind to start.
---
coregrind/vgdb.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c
index 21e67c65b..8ec424077 100644
--- a/coregrind/vgdb.c
+++ b/coregrind/vgdb.c
@@ -178,14 +178,20 @@ void add_written(int nrw)
static int shared_mem_fd = -1;
static
-void map_vgdbshared(char* shared_mem)
+void map_vgdbshared(char* shared_mem, int check_trials)
{
struct stat fdstat;
void **s;
int tries = 50;
int err;
- /* valgrind might still be starting up, give it 5 seconds. */
+ /* valgrind might still be starting up, give it 5 seconds by
+ * default, or check_trails seconds if it is set by --wait
+ * to more than a second. */
+ if (check_trials > 1) {
+ DEBUG(1, "check_trials %d\n", check_trials);
+ tries = check_trials * 10;
+ }
do {
shared_mem_fd = open(shared_mem, O_RDWR | O_CLOEXEC);
err = errno;
@@ -581,7 +587,7 @@ void wait_for_gdb_connect(int in_port)
/* prepares the FIFOs filenames, map the shared memory. */
static
-void prepare_fifos_and_shared_mem(int pid)
+void prepare_fifos_and_shared_mem(int pid, int check_trials)
{
const HChar *user, *host;
unsigned len;
@@ -610,7 +616,7 @@ void prepare_fifos_and_shared_mem(int pid)
DEBUG(1, "vgdb: using %s %s %s\n",
from_gdb_to_pid, to_gdb_from_pid, shared_mem);
- map_vgdbshared(shared_mem);
+ map_vgdbshared(shared_mem, check_trials);
}
static void
@@ -1303,7 +1309,7 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir,
/* Do multi stuff. */
static
-void do_multi_mode(void)
+void do_multi_mode(int check_trials)
{
char *buf = vmalloc(PBUFSIZ+1);
char *q_buf = vmalloc(PBUFSIZ+1); //save the qSupported packet sent by gdb
@@ -1458,7 +1464,7 @@ void do_multi_mode(void)
if (res == 0) {
// Lets report we Stopped with SIGTRAP (05).
send_packet ("S05", noackmode);
- prepare_fifos_and_shared_mem(valgrind_pid);
+ prepare_fifos_and_shared_mem(valgrind_pid, check_trials);
DEBUG(1, "from_gdb_to_pid %s, to_gdb_from_pid %s\n",
from_gdb_to_pid, to_gdb_from_pid);
// gdb_relay is an endless loop till valgrind quits.
@@ -2392,7 +2398,8 @@ int main(int argc, char** argv)
if (!multi_mode) {
pid = search_arg_pid(arg_pid, check_trials, show_list);
- prepare_fifos_and_shared_mem(pid);
+ /* We pass 1 for check_trails here, because search_arg_pid already waited. */
+ prepare_fifos_and_shared_mem(pid, 1);
} else {
pid = 0;
}
@@ -2413,7 +2420,9 @@ int main(int argc, char** argv)
}
if (multi_mode) {
- do_multi_mode ();
+ /* check_trails is the --wait argument in seconds, defaulting to 1
+ * if not given. */
+ do_multi_mode (check_trials);
} else if (last_command >= 0) {
standalone_send_commands(pid, last_command, commands);
} else {
--
2.39.2
|
|
From: Paul F. <pa...@so...> - 2023-04-25 05:37:23
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=8f1e09be1634274654217fa095afcc6d83fa8e35 commit 8f1e09be1634274654217fa095afcc6d83fa8e35 Author: Paul Floyd <pj...@wa...> Date: Tue Apr 25 07:36:10 2023 +0200 Add new DHAT userreqs to NEWS Diff: --- NEWS | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS b/NEWS index f29c756e49..7974f0c2e9 100644 --- a/NEWS +++ b/NEWS @@ -132,6 +132,12 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. - Valgrind now contains python code that defines GDB massif front end monitor commands. See CORE CHANGES. +* 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. + * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" |
|
From: Carl L. <ce...@us...> - 2023-04-24 21:29:35
|
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.
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)
The results on Power 9 and Power 8 are fine as well.
Other than the autoconf message, the RC2 testing looks good on Power.
Note, the autoconf issue doesn't seem to impact the ability to
configure and run Valgrind.
Carl
|