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
|
|
From: Paul F. <pa...@so...> - 2023-05-07 07:56:37
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=cfd58a2e6dc208c436587af24bda5a558e17d15a commit cfd58a2e6dc208c436587af24bda5a558e17d15a Author: Paul Floyd <pj...@wa...> Date: Sun May 7 09:54:50 2023 +0200 Linux Helgrind: add suppression for intermittent failure in getaddrinfo regtest Causes intermittent failure on gcc110 ppc Diff: --- glibc-2.X-helgrind.supp.in | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/glibc-2.X-helgrind.supp.in b/glibc-2.X-helgrind.supp.in index d46a7a1166..6e57e4c56a 100644 --- a/glibc-2.X-helgrind.supp.in +++ b/glibc-2.X-helgrind.supp.in @@ -311,3 +311,9 @@ ... fun:getaddrinfo } + +{ + helgrind---_nss_dns_gethostbyname4_r + Helgrind:Race + fun:_nss_dns_gethostbyname4_r +} |
|
From: Paul F. <pa...@so...> - 2023-05-06 11:33:39
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=5ea25f0b0ae711bd30c6d8b21db33a633ec3e4b9 commit 5ea25f0b0ae711bd30c6d8b21db33a633ec3e4b9 Author: Paul Floyd <pj...@wa...> Date: Sat May 6 13:30:44 2023 +0200 FreeBSD regtest: add small hack to mcclean_after_fork gdb script As far as I can tell this was a regression in FreeBSD gdb around Aug 2022 when the default install upgraded from 11.2 to 12.1 Diff: --- gdbserver_tests/mcclean_after_fork.stdinB.gdb | 3 +++ gdbserver_tests/mcclean_after_fork.stdoutB.exp | 1 + 2 files changed, 4 insertions(+) diff --git a/gdbserver_tests/mcclean_after_fork.stdinB.gdb b/gdbserver_tests/mcclean_after_fork.stdinB.gdb index bd2a5685f2..bbe795f95e 100644 --- a/gdbserver_tests/mcclean_after_fork.stdinB.gdb +++ b/gdbserver_tests/mcclean_after_fork.stdinB.gdb @@ -15,6 +15,9 @@ continue # put a read watchpoint on mem # we expect that the read watchpoint is not triggered in the child # (as we expect it will be cleared at fork). +# On FreeBSD directly calling rwatch mem causes an error +# calling print first fixes that as a workaround +p mem rwatch mem # continue diff --git a/gdbserver_tests/mcclean_after_fork.stdoutB.exp b/gdbserver_tests/mcclean_after_fork.stdoutB.exp index 590e4c93b9..c7bdba12d2 100644 --- a/gdbserver_tests/mcclean_after_fork.stdoutB.exp +++ b/gdbserver_tests/mcclean_after_fork.stdoutB.exp @@ -4,6 +4,7 @@ Breakpoint 3 at 0x........: file clean_after_fork.c, line 22. Continuing. Breakpoint 1, main () at clean_after_fork.c:9 9 pid = fork(); +$1 = 0 Hardware read watchpoint 4: mem Continuing. Hardware read watchpoint 4: mem |
|
From: Paul F. <pa...@so...> - 2023-05-06 05:55:18
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=92a661ebf328b4cf0027234a33952e6e13964b5d commit 92a661ebf328b4cf0027234a33952e6e13964b5d Author: Paul Floyd <pj...@wa...> Date: Sat May 6 07:54:45 2023 +0200 Bug 469049 - link failure on ppc64 (big endian) valgrind 3.20 Diff: --- NEWS | 1 + coregrind/Makefile.am | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index f44cfde1dc..0b54c9cb7b 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,7 @@ bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. +469049 link failure on ppc64 (big endian) valgrind 3.20 469146 massif --ignore-fn does not ignore inlined functions To see details of a given bug, visit diff --git a/coregrind/Makefile.am b/coregrind/Makefile.am index 80115f21fe..553211782f 100644 --- a/coregrind/Makefile.am +++ b/coregrind/Makefile.am @@ -334,7 +334,6 @@ COREGRIND_SOURCES_COMMON = \ m_seqmatch.c \ m_signals.c \ m_sparsewa.c \ - m_stacks.c \ m_stacktrace.c \ m_syscall.c \ m_threadstate.c \ @@ -394,7 +393,6 @@ COREGRIND_SOURCES_COMMON = \ m_dispatch/dispatch-x86-solaris.S \ m_dispatch/dispatch-amd64-solaris.S \ m_gdbserver/inferiors.c \ - m_gdbserver/m_gdbserver.c \ m_gdbserver/regcache.c \ m_gdbserver/remote-utils.c \ m_gdbserver/server.c \ @@ -493,7 +491,9 @@ COREGRIND_SOURCES_COMMON = \ # These objects are added to the libcoregrind library. NOLTO_COREGRIND_SOURCES_COMMON = \ m_libcsetjmp.c \ - m_main.c + m_main.c \ + m_stacks.c \ + m_gdbserver/m_gdbserver.c noinst_LIBRARIES = libnolto_coregrind-@VGCONF_ARCH_PRI@-@VGCONF_OS@.a libnolto_coregrind_@VGCONF_ARCH_PRI@_@VGCONF_OS@_a_SOURCES = \ $(NOLTO_COREGRIND_SOURCES_COMMON) |
|
From: Paul F. <pa...@so...> - 2023-05-06 05:47:07
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=645de069956aa667b924026d2125433461766e4d commit 645de069956aa667b924026d2125433461766e4d Author: Paul Floyd <pj...@wa...> Date: Sat May 6 07:45:47 2023 +0200 Bug 469146 - massif --ignore-fn does not ignore inlined functions Diff: --- .gitignore | 1 + NEWS | 2 +- coregrind/m_debuginfo/debuginfo.c | 26 +++++++++++++++++++++++++ include/pub_tool_debuginfo.h | 4 +++- massif/docs/ms-manual.xml | 11 +++++++++++ massif/ms_main.c | 31 ++++++++++++++++++++++++----- massif/tests/Makefile.am | 4 ++++ massif/tests/bug469146.cpp | 41 +++++++++++++++++++++++++++++++++++++++ massif/tests/bug469146.post.exp | 38 ++++++++++++++++++++++++++++++++++++ massif/tests/bug469146.stderr.exp | 2 ++ massif/tests/bug469146.vgtest | 8 ++++++++ 11 files changed, 161 insertions(+), 7 deletions(-) diff --git a/.gitignore b/.gitignore index 6155f8f355..076e168ded 100644 --- a/.gitignore +++ b/.gitignore @@ -772,6 +772,7 @@ /massif/tests/basic /massif/tests/basic_malloc /massif/tests/big-alloc +/massif/tests/bug469146 /massif/tests/culling1 /massif/tests/culling2 /massif/tests/custom_alloc diff --git a/NEWS b/NEWS index e269d128b9..f44cfde1dc 100644 --- a/NEWS +++ b/NEWS @@ -26,7 +26,7 @@ bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. - +469146 massif --ignore-fn does not ignore inlined functions To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c index 2d2accc999..22b41def21 100644 --- a/coregrind/m_debuginfo/debuginfo.c +++ b/coregrind/m_debuginfo/debuginfo.c @@ -2289,6 +2289,32 @@ Bool VG_(get_fnname) ( DiEpoch ep, Addr a, const HChar** buf ) /*offsetP*/NULL ); } + +Bool VG_(get_fnname_inl) ( DiEpoch ep, Addr a, const HChar** buf, + const InlIPCursor* iipc ) +{ + if (iipc) { + vg_assert(is_DI_valid_for_epoch(iipc->di, ep)); + } + + if (is_bottom(iipc)) { + return get_sym_name ( /*C++-demangle*/True, /*Z-demangle*/True, + /*below-main-renaming*/True, + ep, a, buf, + /*match_anywhere_in_fun*/True, + /*show offset?*/False, + /*text sym*/True, + /*offsetP*/NULL ); + } else { + const DiInlLoc *next_inl = iipc && iipc->next_inltab >= 0 + ? & iipc->di->inltab[iipc->next_inltab] + : NULL; + vg_assert (next_inl); + *buf = next_inl->inlinedfn; + return True; + } +} + /* This is available to tools... always demangle C++ names, match anywhere in function, and show offset if nonzero. NOTE: See IMPORTANT COMMENT above about persistence and ownership diff --git a/include/pub_tool_debuginfo.h b/include/pub_tool_debuginfo.h index 078c562b8e..7631ff67a6 100644 --- a/include/pub_tool_debuginfo.h +++ b/include/pub_tool_debuginfo.h @@ -210,7 +210,9 @@ extern Bool VG_(next_IIPC)(InlIPCursor *iipc); /* Free all memory associated with iipc. */ extern void VG_(delete_IIPC)(InlIPCursor *iipc); - +/* Similar to VG_(get_fnname) but uses InlIPCursor and handles inline functions */ +extern Bool VG_(get_fnname_inl) ( DiEpoch ep, Addr a, const HChar** fnname, + const InlIPCursor* iipc ); /* Get an XArray of StackBlock which describe the stack (auto) blocks for this ip. The caller is expected to free the XArray at some diff --git a/massif/docs/ms-manual.xml b/massif/docs/ms-manual.xml index b589071556..3dff259952 100644 --- a/massif/docs/ms-manual.xml +++ b/massif/docs/ms-manual.xml @@ -760,6 +760,17 @@ various places online. <screen><![CDATA[ --alloc-fn='operator new(unsigned, std::nothrow_t const&)' ]]></screen> + Arguments of type <computeroutput>size_t</computeroutput> need to be replaced + with <computeroutput>unsigned long</computeroutput> on 64bit platforms and <computeroutput>unsigned</computeroutput> + on 32bit platforms. + </para> + + <para><option>--alloc-fn</option> will work with inline functions. + Inline function names are not mangled, which means that you only need + to provide the function name and not the argument list. + </para> + + <para><option>--alloc-fn</option> does not support wildcards. </para> </listitem> </varlistentry> diff --git a/massif/ms_main.c b/massif/ms_main.c index f3500c367d..1040ad53f4 100644 --- a/massif/ms_main.c +++ b/massif/ms_main.c @@ -506,6 +506,8 @@ void filter_IPs (Addr* ips, Int n_ips, { Int i; Bool top_has_fnname = False; + Bool is_alloc_fn = False; + Bool is_inline_fn = False; const HChar *fnname; *top = 0; @@ -519,9 +521,21 @@ void filter_IPs (Addr* ips, Int n_ips, // 0x1 0x2 0x3 alloc func1 main // became 0x1 0x2 0x3 func1 main const DiEpoch ep = VG_(current_DiEpoch)(); - for (i = *top; i < n_ips; i++) { - top_has_fnname = VG_(get_fnname)(ep, ips[*top], &fnname); - if (top_has_fnname && VG_(strIsMemberXA)(alloc_fns, fnname)) { + InlIPCursor *iipc = NULL; + + for (i = *top; i < n_ips; ++i) { + iipc = VG_(new_IIPC)(ep, ips[i]); + do { + top_has_fnname = VG_(get_fnname_inl)(ep, ips[i], &fnname, iipc); + is_alloc_fn = top_has_fnname && VG_(strIsMemberXA)(alloc_fns, fnname); + is_inline_fn = VG_(next_IIPC)(iipc); + if (is_alloc_fn && is_inline_fn) { + VERB(4, "filtering inline alloc fn %s\n", fnname); + } + } while (is_alloc_fn && is_inline_fn); + VG_(delete_IIPC)(iipc); + + if (is_alloc_fn) { VERB(4, "filtering alloc fn %s\n", fnname); (*top)++; (*n_ips_sel)--; @@ -534,8 +548,15 @@ void filter_IPs (Addr* ips, Int n_ips, if (*n_ips_sel > 0 && VG_(sizeXA)(ignore_fns) > 0) { if (!top_has_fnname) { // top has no fnname => search for the first entry that has a fnname - for (i = *top; i < n_ips && !top_has_fnname; i++) { - top_has_fnname = VG_(get_fnname)(ep, ips[i], &fnname); + for (i = *top; i < n_ips && !top_has_fnname; ++i) { + iipc = VG_(new_IIPC)(ep, ips[i]); + do { + top_has_fnname = VG_(get_fnname_inl)(ep, ips[i], &fnname, iipc); + if (top_has_fnname) { + break; + } + } while (VG_(next_IIPC)(iipc)); + VG_(delete_IIPC)(iipc); } } if (top_has_fnname && VG_(strIsMemberXA)(ignore_fns, fnname)) { diff --git a/massif/tests/Makefile.am b/massif/tests/Makefile.am index 84c9b1273a..2f3a84ecc7 100644 --- a/massif/tests/Makefile.am +++ b/massif/tests/Makefile.am @@ -11,6 +11,7 @@ EXTRA_DIST = \ big-alloc.post.exp big-alloc.post.exp-64bit big-alloc.post.exp-ppc64 \ big-alloc.stderr.exp big-alloc.vgtest \ big-alloc.post.exp-x86-freebsd \ + bug469146.post.exp bug469146.stderr.exp bug469146.vgtest \ deep-A.post.exp deep-A.stderr.exp deep-A.vgtest \ deep-B.post.exp deep-B.stderr.exp deep-B.vgtest \ deep-C.post.exp deep-C.stderr.exp deep-C.vgtest \ @@ -59,6 +60,7 @@ check_PROGRAMS = \ alloc-fns \ basic \ big-alloc \ + bug469146 \ culling1 culling2 \ custom_alloc \ deep \ @@ -86,6 +88,8 @@ AM_CFLAGS += $(AM_FLAG_M3264_PRI) AM_CXXFLAGS += $(AM_FLAG_M3264_PRI) # C++ tests +bug469146_SOURCES = bug469146.cpp +bug469146_CXXFLAGS = $(AM_CFLAGS) -O2 new_cpp_SOURCES = new-cpp.cpp overloaded_new_SOURCES = overloaded-new.cpp # pre C++11 compilers don't have exception specs diff --git a/massif/tests/bug469146.cpp b/massif/tests/bug469146.cpp new file mode 100644 index 0000000000..268f07c0a8 --- /dev/null +++ b/massif/tests/bug469146.cpp @@ -0,0 +1,41 @@ +#include <cstdlib> + +// this is inline so it filters as "filter_function1" +static inline int* filter_function1(std::size_t size) +{ + return new int[size]; +} + +// this is out of line C++ +// int is deliberately used here instead of size_t +// so that it is 32/b4 bit portable +// this filters as "filter_function2(int)" +int* __attribute__((optnone)) __attribute__((noinline)) filter_function2(int size) +{ + return new int[static_cast<std::size_t>(size)]; +} + +// finally extern "C" +// this filters as "filter_function3" +extern "C" +int* __attribute__((optnone)) __attribute__((noinline)) filter_function3(std::size_t size) +{ + return new int[size]; +} + +size_t func() +{ + int * mem1 = filter_function1(1000U); + int * mem2 = filter_function2(1000); + int * mem3 = filter_function3(1000U); + delete [] mem1; + delete [] mem2; + delete [] mem3; + + return (size_t)mem1/2 + (size_t)mem2/2 + (size_t)mem3/2; +} + +int main() +{ + return func(); +} diff --git a/massif/tests/bug469146.post.exp b/massif/tests/bug469146.post.exp new file mode 100644 index 0000000000..1e9936cbe1 --- /dev/null +++ b/massif/tests/bug469146.post.exp @@ -0,0 +1,38 @@ +-------------------------------------------------------------------------------- +Command: ./bug469146 +Massif arguments: --stacks=no --time-unit=B --massif-out-file=massif.out --ignore-fn=__part_load_locale --ignore-fn=__time_load_locale --ignore-fn=dwarf2_unwind_dyld_add_image_hook --ignore-fn=get_or_create_key_element --ignore-fn=_GLOBAL__sub_I_eh_alloc.cc --ignore-fn=call_init.part.0 --ignore-fn=call_init --ignore-fn=filter_function1 --ignore-fn=filter_function2(int) --ignore-fn=filter_function3 +ms_print arguments: massif.out +-------------------------------------------------------------------------------- + + + B + 1^ + | + | + | + | + | + | + | + | + | + | + | + | + | + | + | + | + | + | + | + 0 +----------------------------------------------------------------------->B + 0 1 + +Number of snapshots: 1 + Detailed snapshots: [] + +-------------------------------------------------------------------------------- + n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B) +-------------------------------------------------------------------------------- + 0 0 0 0 0 0 diff --git a/massif/tests/bug469146.stderr.exp b/massif/tests/bug469146.stderr.exp new file mode 100644 index 0000000000..139597f9cb --- /dev/null +++ b/massif/tests/bug469146.stderr.exp @@ -0,0 +1,2 @@ + + diff --git a/massif/tests/bug469146.vgtest b/massif/tests/bug469146.vgtest new file mode 100644 index 0000000000..68585a4514 --- /dev/null +++ b/massif/tests/bug469146.vgtest @@ -0,0 +1,8 @@ +prog: bug469146 +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 +vgopts: --ignore-fn=call_init +vgopts: --ignore-fn=filter_function1 --ignore-fn="filter_function2(int)" --ignore-fn=filter_function3 +post: perl ../../massif/ms_print massif.out | sed 's/gcc[0-9]*/gcc/' | ../../tests/filter_addresses +cleanup: rm massif.out |
|
From: Paul F. <pa...@so...> - 2023-05-06 05:30:54
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=c324a6b1396e9e3827e4625616fc75c6d926a772 commit c324a6b1396e9e3827e4625616fc75c6d926a772 Author: Paul Floyd <pj...@wa...> Date: Sat May 6 07:28:51 2023 +0200 FreeBSD: deactivate helgrind/tests/tls_threads No libc tunable, and I haven't seen any way to hack the libc internals via debuginfo as was previously done on Linux. Diff: --- helgrind/tests/tls_threads.vgtest | 1 + 1 file changed, 1 insertion(+) diff --git a/helgrind/tests/tls_threads.vgtest b/helgrind/tests/tls_threads.vgtest index 5fb4587372..aea30e565a 100644 --- a/helgrind/tests/tls_threads.vgtest +++ b/helgrind/tests/tls_threads.vgtest @@ -1,2 +1,3 @@ +prereq: ! ../../tests/os_test freebsd prog: tls_threads vgopts: -q --sim-hints=no-nptl-pthread-stackcache |
|
From: Paul F. <pa...@so...> - 2023-05-05 20:19:53
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=40b914f0d09c1e021e7398a17ab5cc7a854f39c8 commit 40b914f0d09c1e021e7398a17ab5cc7a854f39c8 Author: Paul Floyd <pj...@wa...> Date: Fri May 5 22:05:36 2023 +0200 Add Helgrind and DRD tests and suppressions for getaddrinfo on Linux Bump version to 3.22.0.GIT The testcase was posted on the freebsd-hackers mailing list. I had time to get suppressions for FreeBSD into 3.21 but ran out of time for the test and Linux suppressions. I did take a look at how thread sanitizer handles this. Basically it intercepts the call, turns off checking, calls the resl function then turns checking back on. I don't see many other similar examples. Might be worth looking at dlopen and atexit. Diff: --- .gitignore | 1 + NEWS | 34 +++++++++++++++++++++++++++++++ configure.ac | 6 +++--- drd/tests/Makefile.am | 2 ++ drd/tests/getaddrinfo.stderr.exp | 0 drd/tests/getaddrinfo.vgtest | 3 +++ glibc-2.X-drd.supp.in | 10 +++++++++ glibc-2.X-helgrind.supp.in | 9 +++++++++ helgrind/tests/Makefile.am | 2 ++ helgrind/tests/getaddrinfo.c | 38 +++++++++++++++++++++++++++++++++++ helgrind/tests/getaddrinfo.stderr.exp | 0 helgrind/tests/getaddrinfo.vgtest | 2 ++ 12 files changed, 104 insertions(+), 3 deletions(-) diff --git a/.gitignore b/.gitignore index 27183b99b9..6155f8f355 100644 --- a/.gitignore +++ b/.gitignore @@ -662,6 +662,7 @@ /helgrind/tests/cond_timedwait_test /helgrind/tests/free_is_write /helgrind/tests/garbage.filtered.out +/helgrind/tests/getaddrinfo /helgrind/tests/hg01_all_ok /helgrind/tests/hg02_deadlock /helgrind/tests/hg03_inherit diff --git a/NEWS b/NEWS index 342a733650..e269d128b9 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,37 @@ +Release 3.22.0 (?? Oct 2023) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, +PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, +MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, +X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and +AMD64/FreeBSD. There is also preliminary support for X86/macOS 10.13, +AMD64/macOS 10.13 and nanoMIPS/Linux. + +* ==================== CORE CHANGES =================== + + +* ================== PLATFORM CHANGES ================= + + +* ==================== TOOL CHANGES =================== + + +* ==================== FIXED BUGS ==================== + +The following bugs have been fixed or resolved. Note that "n-i-bz" +stands for "not in bugzilla" -- that is, a bug that was reported to us +but never got a bugzilla entry. We encourage you to file bugs in +bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather +than mailing the developers (or mailing lists) directly -- bugs that +are not entered into bugzilla tend to get forgotten about or ignored. + + + +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. + Release 3.21.0 (28 Apr 2023) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/configure.ac b/configure.ac index 79b17f3940..15fbf5ea20 100755 --- a/configure.ac +++ b/configure.ac @@ -15,10 +15,10 @@ # Also set the (expected/last) release date here. # Do not forget to rerun ./autogen.sh m4_define([v_major_ver], [3]) -m4_define([v_minor_ver], [21]) +m4_define([v_minor_ver], [22]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], []) -m4_define([v_rel_date], ["28 Apr 2023"]) +m4_define([v_suffix_ver], [GIT]) +m4_define([v_rel_date], ["?? Oct 2023"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], diff --git a/drd/tests/Makefile.am b/drd/tests/Makefile.am index 7ea83cbf7e..5482cf7be4 100755 --- a/drd/tests/Makefile.am +++ b/drd/tests/Makefile.am @@ -152,6 +152,8 @@ EXTRA_DIST = \ hold_lock_1.vgtest \ hold_lock_2.stderr.exp \ hold_lock_2.vgtest \ + getaddrinfo.stderr.exp \ + getaddrinfo.vgtest \ linuxthreads_det.stderr.exp \ linuxthreads_det.stderr.exp-linuxthreads \ linuxthreads_det.stdout.exp \ diff --git a/drd/tests/getaddrinfo.stderr.exp b/drd/tests/getaddrinfo.stderr.exp new file mode 100644 index 0000000000..e69de29bb2 diff --git a/drd/tests/getaddrinfo.vgtest b/drd/tests/getaddrinfo.vgtest new file mode 100644 index 0000000000..6faa2b6bde --- /dev/null +++ b/drd/tests/getaddrinfo.vgtest @@ -0,0 +1,3 @@ +prereq: ./supported_libpthread +vgopts: -q +prog: ../../helgrind/tests/getaddrinfo diff --git a/glibc-2.X-drd.supp.in b/glibc-2.X-drd.supp.in index 4c6bdb6a1a..9f8fda9f4f 100644 --- a/glibc-2.X-drd.supp.in +++ b/glibc-2.X-drd.supp.in @@ -351,3 +351,13 @@ ... fun:_ZN5boost6detail23set_current_thread_dataEPNS0_16thread_data_baseE } + +# +# Suppression patterrns for posix functions +{ + drd-libc-getaddrinfo + drd:ConflictingAccess + ... + fun:getaddrinfo +} + diff --git a/glibc-2.X-helgrind.supp.in b/glibc-2.X-helgrind.supp.in index 0f76ad0e9a..d46a7a1166 100644 --- a/glibc-2.X-helgrind.supp.in +++ b/glibc-2.X-helgrind.supp.in @@ -302,3 +302,12 @@ Helgrind:Race fun:gomp_ordered_last } + +#################################################### +# posix functions that are thread safe +{ + helgrind---getaddrinfo + Helgrind:Race + ... + fun:getaddrinfo +} diff --git a/helgrind/tests/Makefile.am b/helgrind/tests/Makefile.am index 5338ea4d6d..13e2d4db66 100755 --- a/helgrind/tests/Makefile.am +++ b/helgrind/tests/Makefile.am @@ -33,6 +33,7 @@ EXTRA_DIST = \ bar_trivial.vgtest bar_trivial.stdout.exp bar_trivial.stderr.exp \ free_is_write.vgtest free_is_write.stdout.exp \ free_is_write.stderr.exp \ + getaddrinfo.vgtest getaddrinfo.stderr.exp \ hg01_all_ok.vgtest hg01_all_ok.stdout.exp hg01_all_ok.stderr.exp \ hg02_deadlock.vgtest hg02_deadlock.stdout.exp hg02_deadlock.stderr.exp \ hg03_inherit.vgtest hg03_inherit.stdout.exp hg03_inherit.stderr.exp \ @@ -153,6 +154,7 @@ check_PROGRAMS = \ cond_timedwait_invalid \ cond_timedwait_test \ free_is_write \ + getaddrinfo \ hg01_all_ok \ hg02_deadlock \ hg03_inherit \ diff --git a/helgrind/tests/getaddrinfo.c b/helgrind/tests/getaddrinfo.c new file mode 100644 index 0000000000..bdb8434588 --- /dev/null +++ b/helgrind/tests/getaddrinfo.c @@ -0,0 +1,38 @@ +#include <netdb.h> +#include <pthread.h> +#include <sys/socket.h> +#include <sys/types.h> + +struct data { + const char *hostname; + struct addrinfo *res; +}; + +struct data threaddat[5] = { + { "www.freebsd.org", 0 }, + { "www.google.com", 0 }, + { "www.freshports.org", 0 }, + { "www.github.com", 0 }, + { "www.kernel.org", 0 } +}; + +pthread_t threads[5]; + +void *resolve(void *d) { + struct data *data = d; + getaddrinfo(data->hostname, 0, 0, &data->res); + return 0; +} + +int main(void) { + int i; + for (i = 0; i < 5; ++i) { + pthread_create(&threads[i], 0, resolve, &threaddat[i]); + } + for (i = 0; i < 5; ++i) { + pthread_join(threads[i], 0); + freeaddrinfo(threaddat[i].res); + } + return 0; +} + diff --git a/helgrind/tests/getaddrinfo.stderr.exp b/helgrind/tests/getaddrinfo.stderr.exp new file mode 100644 index 0000000000..e69de29bb2 diff --git a/helgrind/tests/getaddrinfo.vgtest b/helgrind/tests/getaddrinfo.vgtest new file mode 100644 index 0000000000..b58c618887 --- /dev/null +++ b/helgrind/tests/getaddrinfo.vgtest @@ -0,0 +1,2 @@ +prog: getaddrinfo +vgopts: -q |
|
From: Paul F. <pj...@wa...> - 2023-04-29 16:22:27
|
On 29-04-23 08:20, Paul Floyd wrote:
>
>
> On 28-04-23 21:33, Carl Love wrote:
>
>> .
>> +->85.79% (72,704B) 0x........: ??? (m_trampoline.S:458)
>> +| ->85.79% (72,704B) 0x........: call_init (dl-init.c:70)
>
> The should be filtered by
>
> vgopts: --ignore-fn=call_init
>
> I need to do some debugging to see what is happening - I can reproduce
> the error on one of the gccfarm machines.
I see what is happening now. The stack in question is
==2756940== at 0x48A4C8C: malloc (vg_replace_malloc.c:431)
==2756940== by 0x58025633: ??? (m_trampoline.S:458)
==2756940== by 0x4007D17: call_init (dl-init.c:70)
==2756940== by 0x4007D17: _dl_init (dl-init.c:117)
==2756940== by 0x40311E7: _dl_start_user (in
/usr/lib/powerpc64-linux-gnu/ld64.so.1)
Note the identical addresses for call_init and _dl_init. I believe that
means that call_init is inlined.
This bit of code in ms_main.c skips over call_init
// top has no fnname => search for the first entry that has a fnname
for (i = *top; i < n_ips && !top_has_fnname; i++) {
top_has_fnname = VG_(get_fnname)(ep, ips[i], &fnname);
}
The workaround is to add _dl_init to the ignore functions.
Otherwise I think that the above loop needs to be modified to use
VG_(next_IIPC)(InlIPCursor *iipc)
I've created a bugzilla item for this
https://bugs.kde.org/show_bug.cgi?id=469146
A+
Paul
|
|
From: Paul F. <pj...@wa...> - 2023-04-29 06:20:22
|
On 28-04-23 21:33, Carl Love wrote: > . > +->85.79% (72,704B) 0x........: ??? (m_trampoline.S:458) > +| ->85.79% (72,704B) 0x........: call_init (dl-init.c:70) The should be filtered by vgopts: --ignore-fn=call_init I need to do some debugging to see what is happening - I can reproduce the error on one of the gccfarm machines. A+ Paul |
|
From: Mark W. <ma...@kl...> - 2023-04-29 00:15:24
|
We are pleased to announce a new release of Valgrind, version 3.21.0, available from https://valgrind.org/downloads/current.html. See the release notes below for details of changes. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy and productive debugging and profiling, -- The Valgrind Developers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and AMD64/FreeBSD. There is also preliminary support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * ==================== CORE CHANGES =================== * When GDB is used to debug a program running under valgrind using the valgrind gdbserver, GDB will automatically load some python code provided in valgrind defining GDB front end commands corresponding to the valgrind monitor commands. These GDB front end commands accept the same format as the monitor commands directly sent to the Valgrind gdbserver. These GDB front end commands provide a better integration in the GDB command line interface, so as to use for example GDB auto-completion, command specific help, searching for a command or command help matching a regexp, ... For relevant monitor commands, GDB will evaluate arguments to make the use of monitor commands easier. For example, instead of having to print the address of a variable 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_points_at &some_struct sizeof(some_struct) instead of: (gdb) p &some_struct $2 = (some_struct_type *) 0x1130a0 <some_struct> (gdb) p sizeof(some_struct) $3 = 40 (gdb) monitor who_point_at 0x1130a0 40 * The vgdb utility now supports extended-remote protocol when invoked with --multi. In this mode the GDB run command is supported. Which means you don't need to run gdb and valgrind from different terminals. So for example to start your program in gdb and run it under valgrind you can do: $ gdb prog (gdb) set remote exec-file prog (gdb) set sysroot / (gdb) target extended-remote | vgdb --multi (gdb) start * The behaviour of realloc with a size of zero can now be changed for tools that intercept malloc. Those tools are memcheck, helgrind, drd, massif and dhat. Realloc implementations generally do one of two things - free the memory like free() and return NULL (GNU libc and ptmalloc). - either free the memory and then allocate a minimum sized block or just return the original pointer. Return NULL if the allocation of the minimum sized block fails (jemalloc, musl, snmalloc, Solaris, macOS). When Valgrind is configured and built it will try to match the OS and libc behaviour. However if you are using a non-default library to replace malloc and family (e.g., musl on a glibc Linux or tcmalloc on FreeBSD) then you can use a command line option to change the behaviour of Valgrind: --realloc-zero-bytes-frees=yes|no [yes on Linux glibc, no otherwise] * ================== PLATFORM CHANGES ================= * Make the address space limit on FreeBSD amd64 128Gbytes (the same as Linux and Solaris, it was 32Gbytes) * ==================== TOOL CHANGES =================== * Memcheck: - When doing a delta leak_search, it is now possible to only output the new loss records compared to the previous leak search. This is available in the memcheck monitor command 'leak_search' by specifying the "new" keyword or in your program by using the client request VALGRIND_DO_NEW_LEAK_CHECK. Whenever a "delta" leak search is done (i.e. when specifying "new" or "increased" or "changed" in the monitor command), the new loss records have a "new" marker. - Valgrind now contains python code that defines GDB memcheck front end monitor commands. See CORE CHANGES. - Performs checks for the use of realloc with a size of zero. This is non-portable and a source of errors. If memcheck detects such a usage it will generate an error realloc() with size 0 followed by the usual callstacks. A switch has been added to allow this to be turned off: --show-realloc-size-zero=yes|no [yes] * Helgrind: - The option ---history-backtrace-size=<number> allows to configure the number of entries to record in the stack traces of "old" accesses. Previously, this number was hardcoded to 8. - Valgrind now contains python code that defines GDB helgrind front end monitor commands. See CORE CHANGES. * Cachegrind: - `--cache-sim=no` is now the default. The cache simulation is old and unlikely to match any real modern machine. This means only the `Ir` event are gathered by default, but that is by far the most useful event. - `cg_annotate`, `cg_diff`, and `cg_merge` have been rewritten in Python. As a result, they all have more flexible command line argument handling, e.g. supporting `--show-percs` and `--no-show-percs` forms as well as the existing `--show-percs=yes` and `--show-percs=no`. - `cg_annotate` has some functional changes. - It's much faster, e.g. 3-4x on common cases. - It now supports diffing (with `--diff`, `--mod-filename`, and `--mod-funcname`) and merging (by passing multiple data files). - It now provides more information at the file and function level. There are now "File:function" and "Function:file" sections. These are very useful for programs that use inlining a lot. - Support for user-annotated files and the `-I`/`--include` option has been removed, because it was of little use and blocked other improvements. - The `--auto` option is renamed `--annotate`, though the old `--auto=yes`/`--auto=no` forms are still supported. - `cg_diff` and `cg_merge` are now deprecated, because `cg_annotate` now does a better job of diffing and merging. - The Cachegrind output file format has changed very slightly, but in ways nobody is likely to notice. * Callgrind: - Valgrind now contains python code that defines GDB callgrind front end monitor commands. See CORE CHANGES. * Massif: - 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 memory. The client request is DHAT_HISTOGRAM_MEMORY. * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. 170510 Don't warn about ioctl of size 0 without direction hint 241072 List tools in --help output 327548 false positive while destroying mutex 382034 Testcases build fixes for musl 351857 confusing error message about valid command line option 374596 inconsistent RDTSCP support on x86_64 392331 Spurious lock not held error from inside pthread_cond_timedwait 397083 Likely false positive "uninitialised value(s)" for __wmemchr_avx2 and __wmemcmp_avx2_movbe 400793 pthread_rwlock_timedwrlock false positive 419054 Unhandled syscall getcpu on arm32 433873 openat2 syscall unimplemented on Linux 434057 Add stdio mode to valgrind's gdbserver 435441 valgrind fails to interpose malloc on musl 1.2.2 due to weak symbol name and no libc soname 436413 Warn about realloc of size zero 439685 compiler warning in callgrind/main.c 444110 priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition. 444487 hginfo test detects an extra lock inside data symbol "_rtld_local" 444488 Use glibc.pthread.stack_cache_size tunable 444568 drd/tests/pth_barrier_thr_cr fails on Fedora 38 445743 "The impossible happened: mutex is locked simultaneously by two threads" while using mutexes with priority inheritance and signals 449309 Missing loopback device ioctl(s) 459476 vgdb: allow address reuse to avoid "address already in use" errorsuse" errors 460356 s390: Sqrt32Fx4 -- cannot reduce tree 462830 WARNING: unhandled amd64-freebsd syscall: 474 463027 broken check for MPX instruction support in assembler 464103 Enhancement: add a client request to DHAT to mark memory to be histogrammed 464476 Firefox fails to start under Valgrind 464609 Valgrind memcheck should support Linux pidfd_open 464680 Show issues caused by memory policies like selinux deny_execmem 464859 Build failures with GCC-13 (drd tsan_unittest) 464969 D language demangling 465435 m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed. 466104 aligned_alloc problems, part 1 467036 Add time cost statistics for Regtest 467482 Build failure on aarch64 Alpine 467714 fdleak_* and rlimit tests fail when parent process has more than 64 descriptors opened 467839 Gdbserver: Improve compatibility of library directory name 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 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. |
|
From: Carl L. <ce...@us...> - 2023-04-28 19:57:10
|
On Fri, 2023-04-28 at 20:30 +0200, Paul Floyd wrote:
>
> On 28-04-23 18:04, Carl Love wrote:
>
> > I don't see any explicit "post" errors printed? So I am clearly
> > missing something. :-)
> >
>
< snip >
> Unfortunately the pesky libc and libstdc++ can get in the way and do
> other, system dependent allocations. These allocations are for stuff
> like exception handlers and dynamic loading.
>
> The --ignore-fn options are supposed to filter out all those extras,
> leaving us with only the calls to operator new and delete.
>
> I thought that you might have a different function on power 10. But
> looking at the diff from what you posted I only see
>
> 47c42
> < ->33.24% (4,000B) 0x........: main (new-cpp.cpp:20)
> ---
> > ->33.24% (4,000B) 0x........: main (new-cpp.cpp:20)
>
> That's an extra trailing whitespace.
>
> Could you post the post.diff files, if they aren't too big?
OK, not too big. Here is the diff.
--- new-cpp.post.exp 2023-04-21 20:54:40.000000000 -0400
+++ new-cpp.post.out 2023-04-24 16:29:56.907990371 -0400
@@ -6,54 +6,61 @@
KB
-11.75^ ###########
- | #
- | #
- | #
- | :::::::#
- | : #
- | : #
- | ::::::: # ::::::::::::
- | : : # :
- | : : # :
- | : : # :
- | : : # :
- | : : # :
- | : : # :
- | ::::::::::::: : # : ::::::
- | : : : # : :
- | : : : # : :
- | : : : # : : ::::::
- | : : : # : : :
- | : : : # : : :
+82.76^ #
+ | ::#::
+ | ::::#: :
+ | ::: ::#: ::::::::::::::::::::::::::::::::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
+ | : : ::#: :::
0 +----------------------------------------------------------------------->K
B
- 0 23.50
+ 0 165.5
-Number of snapshots: 10
- Detailed snapshots: [5 (peak)]
+Number of snapshots: 12
+ Detailed snapshots: [6 (peak)]
-------------------------------------------------------------------------------
-
n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B)
-------------------------------------------------------------------------------
-
0 0 0 0 0 0
- 1 4,008 4,008 4,000 8 0
- 2 8,016 8,016 8,000 16 0
- 3 10,024 10,024 10,000 24 0
- 4 12,032 12,032 12,000 32 0
- 5 12,032 12,032 12,000 32 0
-99.73% (12,000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc
.
-->33.24% (4,000B) 0x........: main (new-cpp.cpp:19)
+ 1 72,712 72,712 72,704 8 0
+ 2 76,720 76,720 76,704 16 0
+ 3 80,728 80,728 80,704 24 0
+ 4 82,736 82,736 82,704 32 0
+ 5 84,744 84,744 84,704 40 0
+ 6 84,744 84,744 84,704 40 0
+99.95% (84,704B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc
.
+->85.79% (72,704B) 0x........: ??? (m_trampoline.S:458)
+| ->85.79% (72,704B) 0x........: call_init (dl-init.c:70)
+| ->85.79% (72,704B) 0x........: _dl_init (dl-init.c:117)
+| ->85.79% (72,704B) 0x........: _dl_start_user (in /usr/lib64/ld64.so.2)
+|
+->04.72% (4,000B) 0x........: main (new-cpp.cpp:19)
|
-->33.24% (4,000B) 0x........: main (new-cpp.cpp:20)
+->04.72% (4,000B) 0x........: main (new-cpp.cpp:20)
|
-->16.62% (2,000B) 0x........: main (new-cpp.cpp:21)
+->02.36% (2,000B) 0x........: main (new-cpp.cpp:21)
|
-->16.62% (2,000B) 0x........: main (new-cpp.cpp:22)
+->02.36% (2,000B) 0x........: main (new-cpp.cpp:22)
-------------------------------------------------------------------------------
-
n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B)
-------------------------------------------------------------------------------
-
- 6 16,040 8,024 8,000 24 0
- 7 20,048 4,016 4,000 16 0
- 8 22,056 2,008 2,000 8 0
- 9 24,064 0 0 0 0
+ 7 88,752 80,736 80,704 32 0
+ 8 92,760 76,728 76,704 24 0
+ 9 94,768 74,720 74,704 16 0
+ 10 96,776 72,712 72,704 8 0
+ 11 169,488 0 0 0 0
|
|
From: Paul F. <pj...@wa...> - 2023-04-28 18:31:10
|
On 28-04-23 18:04, Carl Love wrote:
> I don't see any explicit "post" errors printed? So I am clearly
> missing something. :-)
>
> I am hoping you can give me a hint here as I am not seeing where the
> issue with the test is. Thanks.
Hi Carl
The test is supposed to be profiling calls to new. That should turn
s* p1 = new s;
s* p2 = new (std::nothrow) s;
char* c1 = new char[2000];
char* c2 = new (std::nothrow) char[2000];
into
KB
11.75^ ###########
| #
| #
| #
| :::::::#
| : #
| : #
| ::::::: # ::::::::::::
| : : # :
| : : # :
| : : # :
| : : # :
| : : # :
| : : # :
| ::::::::::::: : # : ::::::
| : : : # : :
| : : : # : :
| : : : # : : :
| : : : # : : :
| : : : # : : :
0
+----------------------------------------------------------------------->KB
0
23.50
Unfortunately the pesky libc and libstdc++ can get in the way and do
other, system dependent allocations. These allocations are for stuff
like exception handlers and dynamic loading.
The --ignore-fn options are supposed to filter out all those extras,
leaving us with only the calls to operator new and delete.
I thought that you might have a different function on power 10. But
looking at the diff from what you posted I only see
47c42
< ->33.24% (4,000B) 0x........: main (new-cpp.cpp:20)
---
> ->33.24% (4,000B) 0x........: main (new-cpp.cpp:20)
That's an extra trailing whitespace.
Could you post the post.diff files, if they aren't too big?
A+
Paul
|
|
From: Carl L. <ce...@us...> - 2023-04-28 17:42:13
|
Paul:
On Thu, 2023-04-27 at 22:01 +0200, Paul Floyd wrote:
> 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.
So, just playing around with this to try and understand what causes the
post failures.
Looking at the new-cpp.vgtest file and the output from running regtes,
It looks like the test is run with the command (edited a little to make
it readable):
valgrind --tool=massif --stacks=no --time-unit=B --massif-out-file=massif.out
--ignore-fn=__part_load_locale --ignore-fn=__time_load_locale
--ignore-fn=dwarf2_unwind_dyld_add_image_hook --ignore-fn=get_or_create_key_element
--ignore-fn=_GLOBAL__sub_I_eh_alloc.cc --ignore-fn=call_init.part.0
--ignore-fn=call_init ./new-cpp
The command line output is:
==789558== Massif, a heap profiler
==789558== Copyright (C) 2003-2017, and GNU GPL'd, by Nicholas Nethercote
==789558== Using Valgrind-3.21.0.RC2 and LibVEX; rerun with -h for copyright info
==789558== Command: ./new-cpp
==789558==
==789558==
The contents of the output file massif.out is:
time_unit: B
#-----------
snapshot=0
#-----------
time=0
mem_heap_B=0
mem_heap_extra_B=0
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=1
#-----------
time=4008
mem_heap_B=4000
mem_heap_extra_B=8
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=2
#-----------
time=8016
mem_heap_B=8000
mem_heap_extra_B=16
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=3
#-----------
time=10024
mem_heap_B=10000
mem_heap_extra_B=24
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=4
#-----------
time=12032
mem_heap_B=12000
mem_heap_extra_B=32
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=5
#-----------
time=12032
mem_heap_B=12000
mem_heap_extra_B=32
mem_stacks_B=0
heap_tree=peak
n4: 12000 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
n0: 4000 0x10000973: main (new-cpp.cpp:19)
n0: 4000 0x1000098F: main (new-cpp.cpp:20)
n0: 2000 0x100009A3: main (new-cpp.cpp:21)
n0: 2000 0x100009BB: main (new-cpp.cpp:22)
#-----------
snapshot=6
#-----------
time=16040
mem_heap_B=8000
mem_heap_extra_B=24
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=7
#-----------
time=20048
mem_heap_B=4000
mem_heap_extra_B=16
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=8
#-----------
time=22056
mem_heap_B=2000
mem_heap_extra_B=8
mem_stacks_B=0
heap_tree=empty
#-----------
snapshot=9
#-----------
time=24064
mem_heap_B=0
mem_heap_extra_B=0
mem_stacks_B=0
heap_tree=empty
I then ran the perl script:
perl ../../massif/ms_print massif.out | sed 's/gcc[0-9]*/gcc/' | ../../tests/filter_addresses
KB
11.75^ ###########
| #
| #
| #
| :::::::#
| : #
| : #
| ::::::: # ::::::::::::
| : : # :
| : : # :
| : : # :
| : : # :
| : : # :
| : : # :
| ::::::::::::: : # : ::::::
| : : : # : :
| : : : # : :
| : : : # : : ::::::
| : : : # : : :
| : : : # : : :
0 +----------------------------------------------------------------------->KB
0 23.50
Number of snapshots: 10
Detailed snapshots: [5 (peak)]
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B)
--------------------------------------------------------------------------------
0 0 0 0 0 0
1 4,008 4,008 4,000 8 0
2 8,016 8,016 8,000 16 0
3 10,024 10,024 10,000 24 0
4 12,032 12,032 12,000 32 0
5 12,032 12,032 12,000 32 0
99.73% (12,000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->33.24% (4,000B) 0x........: main (new-cpp.cpp:19)
|
->33.24% (4,000B) 0x........: main (new-cpp.cpp:20)
|
->16.62% (2,000B) 0x........: main (new-cpp.cpp:21)
|
->16.62% (2,000B) 0x........: main (new-cpp.cpp:22)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) extra-heap(B) stacks(B)
--------------------------------------------------------------------------------
6 16,040 8,024 8,000 24 0
7 20,048 4,016 4,000 16 0
8 22,056 2,008 2,000 8 0
9 24,064 0 0 0 0
I don't see any explicit "post" errors printed? So I am clearly
missing something. :-)
I am hoping you can give me a hint here as I am not seeing where the
issue with the test is. Thanks.
Carl
|
|
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 +} |