You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(2) |
2
(9) |
|
3
(1) |
4
|
5
(1) |
6
(3) |
7
(1) |
8
|
9
(3) |
|
10
|
11
(4) |
12
|
13
(24) |
14
(14) |
15
(22) |
16
|
|
17
|
18
(4) |
19
(4) |
20
(3) |
21
|
22
|
23
|
|
24
|
25
(2) |
26
|
27
(2) |
28
|
29
|
30
|
|
31
|
|
|
|
|
|
|
|
From: Mark W. <ma...@so...> - 2020-05-11 08:46:05
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=968bddcd4b4a6565fcd120523c7b33bfd77b5c65 commit 968bddcd4b4a6565fcd120523c7b33bfd77b5c65 Author: Nicholas Nethercote <nne...@mo...> Date: Thu May 7 11:50:55 2020 +1000 Fix reads and writes counts in DHAT. If you do `malloc(100)` followed by `realloc(200)`, DHAT now adds 100 bytes to the read and write counts for the implicit `memcpy`. This gives more reasonable results. I have long been surprised by low writes-per-byte values of around 0.35 for vectors that are grown by doubling. Counting the implicit `memcpy` increases those numbers to well above 0.5, which is what you'd expect. The commit also adds a section to the DHAT docs about `realloc`, because there is some non-obvious behaviour, some of which confused me just a couple of days ago. Diff: --- NEWS | 4 ++++ dhat/dh_main.c | 19 ++++++++++++++---- dhat/docs/dh-manual.xml | 47 +++++++++++++++++++++++++++++++++++++++++++++ dhat/tests/basic.c | 8 +++++--- dhat/tests/basic.stderr.exp | 6 +++--- 5 files changed, 74 insertions(+), 10 deletions(-) diff --git a/NEWS b/NEWS index 5179c7f894..53908689a6 100644 --- a/NEWS +++ b/NEWS @@ -33,6 +33,10 @@ support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * DHAT: + - The implicit memcpy done by each call to realloc now counts towards the + read and write counts of resized heap blocks, making those counts higher + and more accurate. + * Cachegrind: - cg_annotate's --auto and --show-percs options now default to 'yes', because diff --git a/dhat/dh_main.c b/dhat/dh_main.c index e13d8b8e3b..565b0ae2d8 100644 --- a/dhat/dh_main.c +++ b/dhat/dh_main.c @@ -62,7 +62,7 @@ static ULong g_max_blocks = 0; static ULong g_max_bytes = 0; static ULong g_max_instrs = 0; -// Values for the entire run. Computed at the end. +// Values for the entire run. Updated each time a block is retired. static ULong g_reads_bytes = 0; static ULong g_writes_bytes = 0; @@ -616,6 +616,13 @@ void* renew_block ( ThreadId tid, void* p_old, SizeT new_req_szB ) // New size is smaller or same; block not moved. resize_Block(bk->ap, bk->req_szB, new_req_szB); bk->req_szB = new_req_szB; + + // Update reads/writes for the implicit copy. Even though we didn't + // actually do a copy, we act like we did, to match up with the fact + // that we treat this as an additional allocation. + bk->reads_bytes += new_req_szB; + bk->writes_bytes += new_req_szB; + return p_old; } else { @@ -636,15 +643,19 @@ void* renew_block ( ThreadId tid, void* p_old, SizeT new_req_szB ) // interval tree at the new place. Do this by removing // and re-adding it. delete_Block_starting_at( (Addr)p_old ); - // now 'bk' is no longer in the tree, but the Block itself - // is still alive + // Now 'bk' is no longer in the tree, but the Block itself + // is still alive. + + // Update reads/writes for the copy. + bk->reads_bytes += bk->req_szB; + bk->writes_bytes += bk->req_szB; // Update the metadata. resize_Block(bk->ap, bk->req_szB, new_req_szB); bk->payload = (Addr)p_new; bk->req_szB = new_req_szB; - // and re-add + // And re-add it to the interval tree. Bool present = VG_(addToFM)( interval_tree, (UWord)bk, (UWord)0/*no val*/); tl_assert(!present); diff --git a/dhat/docs/dh-manual.xml b/dhat/docs/dh-manual.xml index da71720c33..bd318f563e 100644 --- a/dhat/docs/dh-manual.xml +++ b/dhat/docs/dh-manual.xml @@ -620,6 +620,53 @@ optimization.</para> </sect1> +<sect1 id="dh-manual.options" xreflabel="Treatment of realloc"> +<title>Treatment of <computeroutput>realloc</computeroutput></title> + +<para><computeroutput>realloc</computeroutput> is a tricky function and there +are several different ways that DHAT could handle it.</para> + +<para>Imagine a <computeroutput>malloc(100)</computeroutput> call followed by +a <computeroutput>realloc(200)</computeroutput> call. This combination is +considered to add two to the total block count, and 300 bytes to the total +bytes count. (An alternative would be to only add one to the total block +count, and 200 bytes to the total bytes count, as if a single +<computeroutput>malloc(200)</computeroutput> call had occurred. While this +would be defensible from a semantic point of view, it is silly from an +operational point of view, because making two calls to allocator functions is +more expensive than one call, and DHAT is a profiler that aims to help with +runtime costs.)</para> + +<para>Furthermore, the implicit copying of the 100 bytes is added to the reads +and writes counts. Without this, the read and write counts would be +under-measured and misleading.</para> + +<para>However, DHAT only increases the current heap size by 100 bytes for this +combination, and does not change the current block count. (As opposed to +increasing the current heap size by 200 bytes and then decreasing it by 100 +bytes.) As a result, it can only increase the global heap peak (if indeed, +this results in a new peak) by 100 bytes.</para> + +<para>Finally, the allocation point assigned to the block allocated by the +<computeroutput>malloc(100)</computeroutput> call is retained once the block +is reallocated. Which means that all 300 bytes are attributed to that +allocation point, and no separate allocation point is created for the +<computeroutput>realloc(200)</computeroutput> call. This may be surprising, +but it has one large benefit.</para> + +<para>Imagine some code that starts with an empty buffer, and then gradually +adds data to that buffer from numerous different points in the code, +reallocating the buffer each time it gets full. (E.g. code generation in a +compiler might work this way.) With the described approach, the first heap +block and all subsequent heap blocks are attributed to the same allocation +point. While this is something of a lie -- the first allocation point isn't +actually responsible for the other allocations -- it is arguably better than +having the allocation points spread around, in a distribution +that unpredictably depends on whenever the reallocation points were +triggered.</para> + +</sect1> + <sect1 id="dh-manual.options" xreflabel="DHAT Command-line Options"> <title>DHAT Command-line Options</title> diff --git a/dhat/tests/basic.c b/dhat/tests/basic.c index 3ac6617a40..abb7ef4364 100644 --- a/dhat/tests/basic.c +++ b/dhat/tests/basic.c @@ -15,12 +15,14 @@ int main(void) c[i + 1000] = c[i]; // read and write 1000 bytes } - char* r = realloc(m, 3000); + char* r = realloc(m, 3000); // read and write 1000 bytes (memcpy) for (int i = 0; i < 500; i++) { r[i + 2000] = 99; // write 500 bytes } - // totals: 1008 read, 1516 write - free(c); + c = realloc(c, 1000); // read and write 1000 bytes (memcpy) + + free(c); + // totals: 3008 read, 3516 write return 0; } diff --git a/dhat/tests/basic.stderr.exp b/dhat/tests/basic.stderr.exp index cc714443dd..c846d1e33a 100644 --- a/dhat/tests/basic.stderr.exp +++ b/dhat/tests/basic.stderr.exp @@ -1,5 +1,5 @@ -Total: 6,000 bytes in 3 blocks +Total: 7,000 bytes in 4 blocks At t-gmax: 5,000 bytes in 2 blocks At t-end: 3,000 bytes in 1 blocks -Reads: 1,008 bytes -Writes: 1,516 bytes +Reads: 3,008 bytes +Writes: 3,516 bytes |
|
From: Mark W. <ma...@so...> - 2020-05-11 08:45:56
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=4bed5a4a0a433278b344a5a54f12ca38b36b48dc commit 4bed5a4a0a433278b344a5a54f12ca38b36b48dc Author: Philippe Waroquiers <phi...@sk...> Date: Sat May 2 20:18:06 2020 +0200 Some further refinement to outer suppressions Diff: --- tests/outer_inner.supp | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/tests/outer_inner.supp b/tests/outer_inner.supp index 2d8a6368a9..1a0f9a002c 100644 --- a/tests/outer_inner.supp +++ b/tests/outer_inner.supp @@ -7,10 +7,9 @@ #==3240== by 0x38037A96: vgPlain_arena_strdup (m_mallocfree.c:2591) #==3240== by 0x38037A96: vgPlain_strdup (m_mallocfree.c:2663) #==3240== by 0x3808C880: process_option (m_main.c:456) -#==3240== by 0x380918AE: early_process_cmd_line_options (m_main.c:909) -#==3240== by 0x380918AE: valgrind_main (m_main.c:1492) -#==3240== by 0x380918AE: _start_in_C_linux (m_main.c:3043) -#==3240== by 0x3808C730: ??? (in /home/philippe/valgrind/git/inner_untouched/callgrind/callgrind-amd64-linux) +# .... +# Note: at startup, we leak twice every option prefixed by the tool name +# and we leak such option if changed dynamically. { "keep duplicated args forever as tools can make copies" Memcheck:Leak @@ -18,8 +17,7 @@ fun:vgPlain_arena_strdup fun:vgPlain_strdup fun:process_option - fun:early_process_cmd_line_options - fun:valgrind_main + } #==4649== 344 bytes in 1 blocks are definitely lost in loss record 75 of 131 |
|
From: Mark W. <ma...@so...> - 2020-05-11 08:45:42
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=c8acc28af12a4c537541c817dd4bc60816c78b32 commit c8acc28af12a4c537541c817dd4bc60816c78b32 Author: Philippe Waroquiers <phi...@sk...> Date: Sat May 2 17:07:00 2020 +0200 Update the 'inner outer' suppression entries Diff: --- tests/outer_inner.supp | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/tests/outer_inner.supp b/tests/outer_inner.supp index 2e548d2154..2d8a6368a9 100644 --- a/tests/outer_inner.supp +++ b/tests/outer_inner.supp @@ -2,21 +2,23 @@ # errors to suppress when an outer runs an inner. # The below suppressions are assuming --read-inline-info=yes is used. -#==4649== 16 bytes in 1 blocks are definitely lost in loss record 6 of 131 -#==4649== at 0x2804262C: vgPlain_arena_malloc (m_mallocfree.c:1771) -#==4649== by 0x28042CB2: vgPlain_arena_strdup (m_mallocfree.c:2325) -#==4649== by 0x28042CB2: vgPlain_strdup (m_mallocfree.c:2391) -#==4649== by 0x280391D9: main_process_cmd_line_options (m_main.c:484) -#==4649== by 0x280391D9: valgrind_main (m_main.c:1965) -#==4649== by 0x2803DB32: _start_in_C_linux (m_main.c:3107) -#==4649== by 0x2803794B: ??? (in /home/philippe/valgrind/inner_trunk_untouched/memcheck/memcheck-x86-linux) +#==3240== 16 bytes in 1 blocks are definitely lost in loss record 1,723 of 5,952 +#==3240== at 0x38035B1B: vgPlain_arena_malloc (m_mallocfree.c:1918) +#==3240== by 0x38037A96: vgPlain_arena_strdup (m_mallocfree.c:2591) +#==3240== by 0x38037A96: vgPlain_strdup (m_mallocfree.c:2663) +#==3240== by 0x3808C880: process_option (m_main.c:456) +#==3240== by 0x380918AE: early_process_cmd_line_options (m_main.c:909) +#==3240== by 0x380918AE: valgrind_main (m_main.c:1492) +#==3240== by 0x380918AE: _start_in_C_linux (m_main.c:3043) +#==3240== by 0x3808C730: ??? (in /home/philippe/valgrind/git/inner_untouched/callgrind/callgrind-amd64-linux) { "keep duplicated args forever as tools can make copies" Memcheck:Leak fun:vgPlain_arena_malloc fun:vgPlain_arena_strdup fun:vgPlain_strdup - fun:main_process_cmd_line_options + fun:process_option + fun:early_process_cmd_line_options fun:valgrind_main } |
|
From: Mark W. <ma...@kl...> - 2020-05-11 07:49:41
|
Hi Nicholas, On Thu, 2020-05-07 at 22:40 +0000, Nicholas Nethercote wrote: > https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=968bddcd4b4a6565fcd120523c7b33bfd77b5c65 > > commit 968bddcd4b4a6565fcd120523c7b33bfd77b5c65 > Author: Nicholas Nethercote <nne...@mo...> > Date: Thu May 7 11:50:55 2020 +1000 > > Fix reads and writes counts in DHAT. > > If you do `malloc(100)` followed by `realloc(200)`, DHAT now adds 100 > bytes to the read and write counts for the implicit `memcpy`. This gives > more reasonable results. > > I have long been surprised by low writes-per-byte values of around 0.35 > for vectors that are grown by doubling. Counting the implicit `memcpy` > increases those numbers to well above 0.5, which is what you'd expect. > > The commit also adds a section to the DHAT docs about `realloc`, because > there is some non-obvious behaviour, some of which confused me just a > couple of days ago. Note that valgrind 3.16.0 just branched. Should this commit also go on the branch before the 3.16.0 release? Thanks, Mark |
|
From: Paul F. <pj...@wa...> - 2020-05-09 19:01:18
|
> On 9 May 2020, at 13:59, Eliot Moss <mo...@cs...> wrote: > >> > > I believe what you are seeing is called "tail call elimination" - if a function ends with a > call, that call can be optimized to a jump, at least under some circumstances. This is > perfectly legitimate. > Hi I know what the optimisation is. I’m not familiar with the heuristics used to try to build the callstack and the dwarf2/3 CFI stack unwinding. So I just wanted to make sure that this difference is to be expected. A+ Paul |
|
From: Eliot M. <mo...@cs...> - 2020-05-09 12:17:16
|
On 5/9/2020 2:42 AM, Paul FLOYD wrote: > Hi > > I've been looking at some differences that I get when building with clang. > > One kind of difference that I see is that Helgrind displays one less element in callstacks. For instance with a GCC build I might get > > ==34086== ---Thread-Announcement------------------------------------------ > ==34086== > ==34086== Thread #2 was created > ==34086== at 0x4D144BA: thr_new (in /lib/libc.so.7) > ==34086== by 0x4C6639C: pthread_create (in /lib/libthr.so.3) > ==34086== by 0x4A5098A: pthread_create_WRK (hg_intercepts.c:433) > ==34086== by 0x4A5199C: pthread_create (hg_intercepts.c:472) > ==34086== by 0x400935: main (tc01_simple_race.c:22) > > but the same with a clang build gives > > ==37539== ---Thread-Announcement------------------------------------------ > ==37539== > ==37539== Thread #3 was created > ==37539== at 0x491E4BA: thr_new (in /lib/libc.so.7) > ==37539== by 0x487039C: pthread_create (in /lib/libthr.so.3) > ==37539== by 0x4855B44: pthread_create_WRK (hg_intercepts.c:434) > ==37539== by 0x400B7A: main (tc21_pthonce.c:87) > > (note there is no pthread_create/hg_intercepts.c line). > > I think that the cause of this is the clang codegen in the helgrind preload lib. > > Here is the GCC codegen, a classic function call > > > 000000000000999f <_vgw00000ZZ_libthrZdsoZa_pthreadZujoin>: > 999f: 55 push %rbp > 99a0: 48 89 e5 mov %rsp,%rbp > 99a3: e8 a5 c1 ff ff callq 5b4d > > 99a8: 5d pop %rbp > 99a9: c3 retq > > Clang optimizes the call and uses a jump > > 000000000000a9f0 <_vgw00000ZZ_libthrZdsoZa_pthreadZucreate>: > a9f0: 55 push %rbp > a9f1: 48 89 e5 mov %rsp,%rbp > a9f4: 5d pop %rbp > a9f5: eb 09 jmp aa00 > > a9f7: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) > a9fe: 00 00 > > Am I right in assuming it is this 'jmp' rather than 'callq / retq' that is causing "VG_(get_StackTrace_wrk)" to see one less element in the callstack? > > The difference goes away if I force 'pthread_create' to be not optimized. > > #define PTH_FUNC(ret_ty, f, args...) \ > ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \ > __attribute__((optnone)) \ > ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args) > > (Not that I'm seriously suggesting that). I believe what you are seeing is called "tail call elimination" - if a function ends with a call, that call can be optimized to a jump, at least under some circumstances. This is perfectly legitimate. Regards - Eliot Moss |
|
From: Paul F. <pj...@wa...> - 2020-05-09 06:43:06
|
Hi I've been looking at some differences that I get when building with clang. One kind of difference that I see is that Helgrind displays one less element in callstacks. For instance with a GCC build I might get ==34086== ---Thread-Announcement------------------------------------------ ==34086== ==34086== Thread #2 was created ==34086== at 0x4D144BA: thr_new (in /lib/libc.so.7) ==34086== by 0x4C6639C: pthread_create (in /lib/libthr.so.3) ==34086== by 0x4A5098A: pthread_create_WRK (hg_intercepts.c:433) ==34086== by 0x4A5199C: pthread_create (hg_intercepts.c:472) ==34086== by 0x400935: main (tc01_simple_race.c:22) but the same with a clang build gives ==37539== ---Thread-Announcement------------------------------------------ ==37539== ==37539== Thread #3 was created ==37539== at 0x491E4BA: thr_new (in /lib/libc.so.7) ==37539== by 0x487039C: pthread_create (in /lib/libthr.so.3) ==37539== by 0x4855B44: pthread_create_WRK (hg_intercepts.c:434) ==37539== by 0x400B7A: main (tc21_pthonce.c:87) (note there is no pthread_create/hg_intercepts.c line). I think that the cause of this is the clang codegen in the helgrind preload lib. Here is the GCC codegen, a classic function call 000000000000999f <_vgw00000ZZ_libthrZdsoZa_pthreadZujoin>: 999f: 55 push %rbp 99a0: 48 89 e5 mov %rsp,%rbp 99a3: e8 a5 c1 ff ff callq 5b4d 99a8: 5d pop %rbp 99a9: c3 retq Clang optimizes the call and uses a jump 000000000000a9f0 <_vgw00000ZZ_libthrZdsoZa_pthreadZucreate>: a9f0: 55 push %rbp a9f1: 48 89 e5 mov %rsp,%rbp a9f4: 5d pop %rbp a9f5: eb 09 jmp aa00 a9f7: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1) a9fe: 00 00 Am I right in assuming it is this 'jmp' rather than 'callq / retq' that is causing "VG_(get_StackTrace_wrk)" to see one less element in the callstack? The difference goes away if I force 'pthread_create' to be not optimized. #define PTH_FUNC(ret_ty, f, args...) \ ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \ __attribute__((optnone)) \ ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args) (Not that I'm seriously suggesting that). A+ Paul |
|
From: Nicholas N. <nj...@so...> - 2020-05-07 22:41:05
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=968bddcd4b4a6565fcd120523c7b33bfd77b5c65 commit 968bddcd4b4a6565fcd120523c7b33bfd77b5c65 Author: Nicholas Nethercote <nne...@mo...> Date: Thu May 7 11:50:55 2020 +1000 Fix reads and writes counts in DHAT. If you do `malloc(100)` followed by `realloc(200)`, DHAT now adds 100 bytes to the read and write counts for the implicit `memcpy`. This gives more reasonable results. I have long been surprised by low writes-per-byte values of around 0.35 for vectors that are grown by doubling. Counting the implicit `memcpy` increases those numbers to well above 0.5, which is what you'd expect. The commit also adds a section to the DHAT docs about `realloc`, because there is some non-obvious behaviour, some of which confused me just a couple of days ago. Diff: --- NEWS | 4 ++++ dhat/dh_main.c | 19 ++++++++++++++---- dhat/docs/dh-manual.xml | 47 +++++++++++++++++++++++++++++++++++++++++++++ dhat/tests/basic.c | 8 +++++--- dhat/tests/basic.stderr.exp | 6 +++--- 5 files changed, 74 insertions(+), 10 deletions(-) diff --git a/NEWS b/NEWS index 5179c7f894..53908689a6 100644 --- a/NEWS +++ b/NEWS @@ -33,6 +33,10 @@ support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * DHAT: + - The implicit memcpy done by each call to realloc now counts towards the + read and write counts of resized heap blocks, making those counts higher + and more accurate. + * Cachegrind: - cg_annotate's --auto and --show-percs options now default to 'yes', because diff --git a/dhat/dh_main.c b/dhat/dh_main.c index e13d8b8e3b..565b0ae2d8 100644 --- a/dhat/dh_main.c +++ b/dhat/dh_main.c @@ -62,7 +62,7 @@ static ULong g_max_blocks = 0; static ULong g_max_bytes = 0; static ULong g_max_instrs = 0; -// Values for the entire run. Computed at the end. +// Values for the entire run. Updated each time a block is retired. static ULong g_reads_bytes = 0; static ULong g_writes_bytes = 0; @@ -616,6 +616,13 @@ void* renew_block ( ThreadId tid, void* p_old, SizeT new_req_szB ) // New size is smaller or same; block not moved. resize_Block(bk->ap, bk->req_szB, new_req_szB); bk->req_szB = new_req_szB; + + // Update reads/writes for the implicit copy. Even though we didn't + // actually do a copy, we act like we did, to match up with the fact + // that we treat this as an additional allocation. + bk->reads_bytes += new_req_szB; + bk->writes_bytes += new_req_szB; + return p_old; } else { @@ -636,15 +643,19 @@ void* renew_block ( ThreadId tid, void* p_old, SizeT new_req_szB ) // interval tree at the new place. Do this by removing // and re-adding it. delete_Block_starting_at( (Addr)p_old ); - // now 'bk' is no longer in the tree, but the Block itself - // is still alive + // Now 'bk' is no longer in the tree, but the Block itself + // is still alive. + + // Update reads/writes for the copy. + bk->reads_bytes += bk->req_szB; + bk->writes_bytes += bk->req_szB; // Update the metadata. resize_Block(bk->ap, bk->req_szB, new_req_szB); bk->payload = (Addr)p_new; bk->req_szB = new_req_szB; - // and re-add + // And re-add it to the interval tree. Bool present = VG_(addToFM)( interval_tree, (UWord)bk, (UWord)0/*no val*/); tl_assert(!present); diff --git a/dhat/docs/dh-manual.xml b/dhat/docs/dh-manual.xml index da71720c33..bd318f563e 100644 --- a/dhat/docs/dh-manual.xml +++ b/dhat/docs/dh-manual.xml @@ -620,6 +620,53 @@ optimization.</para> </sect1> +<sect1 id="dh-manual.options" xreflabel="Treatment of realloc"> +<title>Treatment of <computeroutput>realloc</computeroutput></title> + +<para><computeroutput>realloc</computeroutput> is a tricky function and there +are several different ways that DHAT could handle it.</para> + +<para>Imagine a <computeroutput>malloc(100)</computeroutput> call followed by +a <computeroutput>realloc(200)</computeroutput> call. This combination is +considered to add two to the total block count, and 300 bytes to the total +bytes count. (An alternative would be to only add one to the total block +count, and 200 bytes to the total bytes count, as if a single +<computeroutput>malloc(200)</computeroutput> call had occurred. While this +would be defensible from a semantic point of view, it is silly from an +operational point of view, because making two calls to allocator functions is +more expensive than one call, and DHAT is a profiler that aims to help with +runtime costs.)</para> + +<para>Furthermore, the implicit copying of the 100 bytes is added to the reads +and writes counts. Without this, the read and write counts would be +under-measured and misleading.</para> + +<para>However, DHAT only increases the current heap size by 100 bytes for this +combination, and does not change the current block count. (As opposed to +increasing the current heap size by 200 bytes and then decreasing it by 100 +bytes.) As a result, it can only increase the global heap peak (if indeed, +this results in a new peak) by 100 bytes.</para> + +<para>Finally, the allocation point assigned to the block allocated by the +<computeroutput>malloc(100)</computeroutput> call is retained once the block +is reallocated. Which means that all 300 bytes are attributed to that +allocation point, and no separate allocation point is created for the +<computeroutput>realloc(200)</computeroutput> call. This may be surprising, +but it has one large benefit.</para> + +<para>Imagine some code that starts with an empty buffer, and then gradually +adds data to that buffer from numerous different points in the code, +reallocating the buffer each time it gets full. (E.g. code generation in a +compiler might work this way.) With the described approach, the first heap +block and all subsequent heap blocks are attributed to the same allocation +point. While this is something of a lie -- the first allocation point isn't +actually responsible for the other allocations -- it is arguably better than +having the allocation points spread around, in a distribution +that unpredictably depends on whenever the reallocation points were +triggered.</para> + +</sect1> + <sect1 id="dh-manual.options" xreflabel="DHAT Command-line Options"> <title>DHAT Command-line Options</title> diff --git a/dhat/tests/basic.c b/dhat/tests/basic.c index 3ac6617a40..abb7ef4364 100644 --- a/dhat/tests/basic.c +++ b/dhat/tests/basic.c @@ -15,12 +15,14 @@ int main(void) c[i + 1000] = c[i]; // read and write 1000 bytes } - char* r = realloc(m, 3000); + char* r = realloc(m, 3000); // read and write 1000 bytes (memcpy) for (int i = 0; i < 500; i++) { r[i + 2000] = 99; // write 500 bytes } - // totals: 1008 read, 1516 write - free(c); + c = realloc(c, 1000); // read and write 1000 bytes (memcpy) + + free(c); + // totals: 3008 read, 3516 write return 0; } diff --git a/dhat/tests/basic.stderr.exp b/dhat/tests/basic.stderr.exp index cc714443dd..c846d1e33a 100644 --- a/dhat/tests/basic.stderr.exp +++ b/dhat/tests/basic.stderr.exp @@ -1,5 +1,5 @@ -Total: 6,000 bytes in 3 blocks +Total: 7,000 bytes in 4 blocks At t-gmax: 5,000 bytes in 2 blocks At t-end: 3,000 bytes in 1 blocks -Reads: 1,008 bytes -Writes: 1,516 bytes +Reads: 3,008 bytes +Writes: 3,516 bytes |
|
From: Robert H. <rob...@mi...> - 2020-05-06 03:49:40
|
I am trying to evaluate the code quality of a JIT, which in our case does not yet have the quality intra and inter procedural data flow analysis that the mature compilers you speak of already have. So the dynamic trace would provide additional insight on where our low hanging fruit is. ________________________________ From: John Reiser <jr...@bi...> Sent: Tuesday, May 5, 2020 7:23 PM To: val...@li... <val...@li...> Subject: [EXTERNAL] Re: [Valgrind-developers] Finding write-after-write On 5/5/20 , Robert Henry via Valgrind-developers wrote: > I'm wondering if there has been any prior work to valgrind to make it optionally report write after write (WaW)? I'd like to use such a tool to find variables that are initialized unnecessarily. That's a job for an optimizing compiler and/or static code analysis tool. Such tools already exist and are well-developed and maintained; use them. Making drd detect WaW (with respect to initialization) is wasted effort. The output of a compiler or static analysis tool is a proof that the first Write is (or is not) superfluous. The output of a dynamic analysis tool is merely a comment that the observed execution had one such path. _______________________________________________ Valgrind-developers mailing list Val...@li... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-developers&data=02%7C01%7Crobhenry%40microsoft.com%7Cb751f7b8c244457b028208d7f16ea2ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243330290588999&sdata=ZBfph8OHeQrwBHPqFVjdD3W9Zg%2B3kIhr43QdiTdfO0Q%3D&reserved=0 |
|
From: John R. <jr...@bi...> - 2020-05-06 03:35:56
|
On 5/5/20 , Robert Henry via Valgrind-developers wrote: > I'm wondering if there has been any prior work to valgrind to make it optionally report write after write (WaW)? I'd like to use such a tool to find variables that are initialized unnecessarily. That's a job for an optimizing compiler and/or static code analysis tool. Such tools already exist and are well-developed and maintained; use them. Making drd detect WaW (with respect to initialization) is wasted effort. The output of a compiler or static analysis tool is a proof that the first Write is (or is not) superfluous. The output of a dynamic analysis tool is merely a comment that the observed execution had one such path. |
|
From: Robert H. <rob...@mi...> - 2020-05-06 01:49:10
|
I'm wondering if there has been any prior work to valgrind to make it optionally report write after write (WaW)? I'd like to use such a tool to find variables that are initialized unnecessarily. I realize it may produce so many positives as to be useless, but careful filtering may help me in my situation. Robert Henry |
|
From: Paul F. <pj...@wa...> - 2020-05-05 21:17:37
|
With some help, I've just been looking at memcheck/tests/varinfo1 This fails when compiled with clang (on Linux and FreeBSD). 1. It seems that clang with optimization elides the calls to malloc. This can be worked around by making the variables volatile without any impact on GCC. 2. The two package versions of clangs that I've installed on FreeBSD (8.0.1 and 9.0.1) don't produce the lineinfo for the last error. (I haven't done any debugging in Valgrind to see if there is a problem there). 3. clang built from source (11.0.0) does produce the lineinfo but the test _still_ fails because there's a diff in the frame number. Does it sound reasonable to a) make the variable volatile and b) add a varinfo1.stderr.exp-clang ? A+ Paul |
|
From: Philippe W. <phi...@so...> - 2020-05-03 01:46:42
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=c8acc28af12a4c537541c817dd4bc60816c78b32 commit c8acc28af12a4c537541c817dd4bc60816c78b32 Author: Philippe Waroquiers <phi...@sk...> Date: Sat May 2 17:07:00 2020 +0200 Update the 'inner outer' suppression entries Diff: --- tests/outer_inner.supp | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/tests/outer_inner.supp b/tests/outer_inner.supp index 2e548d2154..2d8a6368a9 100644 --- a/tests/outer_inner.supp +++ b/tests/outer_inner.supp @@ -2,21 +2,23 @@ # errors to suppress when an outer runs an inner. # The below suppressions are assuming --read-inline-info=yes is used. -#==4649== 16 bytes in 1 blocks are definitely lost in loss record 6 of 131 -#==4649== at 0x2804262C: vgPlain_arena_malloc (m_mallocfree.c:1771) -#==4649== by 0x28042CB2: vgPlain_arena_strdup (m_mallocfree.c:2325) -#==4649== by 0x28042CB2: vgPlain_strdup (m_mallocfree.c:2391) -#==4649== by 0x280391D9: main_process_cmd_line_options (m_main.c:484) -#==4649== by 0x280391D9: valgrind_main (m_main.c:1965) -#==4649== by 0x2803DB32: _start_in_C_linux (m_main.c:3107) -#==4649== by 0x2803794B: ??? (in /home/philippe/valgrind/inner_trunk_untouched/memcheck/memcheck-x86-linux) +#==3240== 16 bytes in 1 blocks are definitely lost in loss record 1,723 of 5,952 +#==3240== at 0x38035B1B: vgPlain_arena_malloc (m_mallocfree.c:1918) +#==3240== by 0x38037A96: vgPlain_arena_strdup (m_mallocfree.c:2591) +#==3240== by 0x38037A96: vgPlain_strdup (m_mallocfree.c:2663) +#==3240== by 0x3808C880: process_option (m_main.c:456) +#==3240== by 0x380918AE: early_process_cmd_line_options (m_main.c:909) +#==3240== by 0x380918AE: valgrind_main (m_main.c:1492) +#==3240== by 0x380918AE: _start_in_C_linux (m_main.c:3043) +#==3240== by 0x3808C730: ??? (in /home/philippe/valgrind/git/inner_untouched/callgrind/callgrind-amd64-linux) { "keep duplicated args forever as tools can make copies" Memcheck:Leak fun:vgPlain_arena_malloc fun:vgPlain_arena_strdup fun:vgPlain_strdup - fun:main_process_cmd_line_options + fun:process_option + fun:early_process_cmd_line_options fun:valgrind_main } |
|
From: Philippe W. <phi...@so...> - 2020-05-02 19:41:43
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=4bed5a4a0a433278b344a5a54f12ca38b36b48dc commit 4bed5a4a0a433278b344a5a54f12ca38b36b48dc Author: Philippe Waroquiers <phi...@sk...> Date: Sat May 2 20:18:06 2020 +0200 Some further refinement to outer suppressions Diff: --- tests/outer_inner.supp | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/tests/outer_inner.supp b/tests/outer_inner.supp index 2d8a6368a9..1a0f9a002c 100644 --- a/tests/outer_inner.supp +++ b/tests/outer_inner.supp @@ -7,10 +7,9 @@ #==3240== by 0x38037A96: vgPlain_arena_strdup (m_mallocfree.c:2591) #==3240== by 0x38037A96: vgPlain_strdup (m_mallocfree.c:2663) #==3240== by 0x3808C880: process_option (m_main.c:456) -#==3240== by 0x380918AE: early_process_cmd_line_options (m_main.c:909) -#==3240== by 0x380918AE: valgrind_main (m_main.c:1492) -#==3240== by 0x380918AE: _start_in_C_linux (m_main.c:3043) -#==3240== by 0x3808C730: ??? (in /home/philippe/valgrind/git/inner_untouched/callgrind/callgrind-amd64-linux) +# .... +# Note: at startup, we leak twice every option prefixed by the tool name +# and we leak such option if changed dynamically. { "keep duplicated args forever as tools can make copies" Memcheck:Leak @@ -18,8 +17,7 @@ fun:vgPlain_arena_strdup fun:vgPlain_strdup fun:process_option - fun:early_process_cmd_line_options - fun:valgrind_main + } #==4649== 344 bytes in 1 blocks are definitely lost in loss record 75 of 131 |
|
From: Mark W. <ma...@so...> - 2020-05-02 15:41:42
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=d772e25995c3400eecf2b6070e0bf3411447c3d1 commit d772e25995c3400eecf2b6070e0bf3411447c3d1 Author: Mark Wielaard <ma...@kl...> Date: Sat May 2 16:21:44 2020 +0200 Remove SGcheck from documentation. Since the SGcheck tool was removed for 3.16.0, also remove it from the manual intro and core sections and the xml-output-protocol4 description. Diff: --- docs/internals/xml-output-protocol4.txt | 49 ++++----------------------------- docs/xml/manual-core.xml | 4 +-- docs/xml/manual-intro.xml | 7 ----- 3 files changed, 7 insertions(+), 53 deletions(-) diff --git a/docs/internals/xml-output-protocol4.txt b/docs/internals/xml-output-protocol4.txt index 3703bbd025..461b8a5044 100644 --- a/docs/internals/xml-output-protocol4.txt +++ b/docs/internals/xml-output-protocol4.txt @@ -4,7 +4,7 @@ 14 October 2011 Protocols 1 through 3 supported Memcheck only. Protocol 4 provides -XML output for Memcheck, Helgrind, DRD and SGcheck. Technically there +XML output for Memcheck, Helgrind and DRD. Technically there are four variants of Protocol 4, one for each tool, since they produce different errors. The four variants differ only in the definition of the ERROR nonterminal and are otherwise identical. @@ -81,7 +81,7 @@ XWHAT, and between AUXWHAT and XAUXWHAT. The definition of Protocol 4 now follows. It is structured similarly to that of the previous protocols, except that there is a separate definition of a nonterminal called TOOLSPECIFIC for each of Memcheck, -Helgrind, DRD and SGcheck. The XWHAT and XAUXWHAT nonterminals also +Helgrind and DRD. The XWHAT and XAUXWHAT nonterminals also have tool-specific components. Apart from that, the structure is common to all supported tools. @@ -199,9 +199,9 @@ the following in sequence: </status> * Zero or more of (either ERRORCOUNTS or TOOLSPECIFIC). In Memcheck's - case these will be complaints from the leak checker. For SGcheck - and Helgrind we don't expect any output here (but the spec does not - guarantee that either). + case these will be complaints from the leak checker. For Helgrind + we don't expect any output here (but the spec does not guarantee that + either). * SUPPCOUNTS, indicating how many times each suppression was used. @@ -571,45 +571,6 @@ The possible values are: indicating probable integer overflow or cast from negative signed -==================================================================== - -TOOLSPECIFIC definition for SGcheck ------------------------------------ - -For SGcheck, a TOOLSPECIFIC is simply an ERROR: - -TOOLSPECIFIC = ERROR - - -ERROR details for SGcheck -------------------------- - -SGcheck does not produce any XWHAT records, despite the fact that -"ERROR definition -- common structure" says that tools may do so. - - -XAUXWHATs (for definition, see above) may contain the following extra -components (along with the mandatory <text>...</text> component): - -* <file>TEXT</file>, as defined in FRAME - -* <line>INT</line>, as defined in FRAME - -* <dir>TEXT</dir>, as defined in FRAME - - -KIND for SGcheck ----------------- -This is a small enumeration indicating roughly the nature of an error. -The possible values are: - - SorG - - Stack or global array inconsistency (roughly speaking, an - overrun of a stack or global array). The <auxwhat> blocks give - further details. - - ==================================================================== TOOLSPECIFIC definition for Helgrind diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml index 72730ec7bb..50904ff82a 100644 --- a/docs/xml/manual-core.xml +++ b/docs/xml/manual-core.xml @@ -995,8 +995,8 @@ that can report errors, e.g. Memcheck, but not Cachegrind.</para> <para>This option is aimed at making life easier for tools that consume Valgrind's output as input, such as GUI front ends. Currently this - option works with Memcheck, Helgrind, DRD and SGcheck. The output - format is specified in the file + option works with Memcheck, Helgrind and DRD. The output format is + specified in the file <computeroutput>docs/internals/xml-output-protocol4.txt</computeroutput> in the source tree for Valgrind 3.5.0 or later.</para> diff --git a/docs/xml/manual-intro.xml b/docs/xml/manual-intro.xml index 79351ba18b..6f730d1ac0 100644 --- a/docs/xml/manual-intro.xml +++ b/docs/xml/manual-intro.xml @@ -59,13 +59,6 @@ and without disturbing the existing structure.</para> block utilisation, and layout inefficiencies.</para> </listitem> - <listitem> - <para><command>SGcheck</command> is an experimental tool that can - detect overruns of stack and global arrays. Its functionality is - complementary to that of Memcheck: SGcheck finds problems that - Memcheck can't, and vice versa..</para> - </listitem> - <listitem> <para><command>BBV</command> is an experimental SimPoint basic block vector generator. It is useful to people doing computer architecture |
|
From: Mark W. <ma...@kl...> - 2020-05-02 15:31:41
|
On Fri, May 01, 2020 at 06:12:46PM +0200, Paul FLOYD wrote: > One little request - could someone please remove exp-sgcheck from .gitignore? Well spotted. I pushed a commit to master and VALGRIND_3_16_BRANCH to remove those and one to mention the removal in the NEWS file. Thanks, Mark |
|
From: Mark W. <ma...@so...> - 2020-05-02 14:51:42
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=aaebe6aa08f09baed68e085da9a8ddaf3ae96227 commit aaebe6aa08f09baed68e085da9a8ddaf3ae96227 Author: Mark Wielaard <ma...@kl...> Date: Sat May 2 16:12:21 2020 +0200 Mention exp-sgcheck removal in NEWS. Diff: --- NEWS | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/NEWS b/NEWS index 04effd80d4..5179c7f894 100644 --- a/NEWS +++ b/NEWS @@ -62,6 +62,15 @@ support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. valgrind will now produce a warning to say the suppression entry will not work, and suggest the needed change. +* exp-sgcheck: + + - The exprimental Stack and Global Array Checking tool has been removed. + It only ever worked on x86 and amd64, and even on those it had a + high false positive rate and was slow. An alternative for detecting + stack and global array overruns is using the AddressSanitizer (ASAN) + facility of the GCC and llvm compilers which require you to rebuild + your code with -fsanitize=address. + * ==================== OTHER CHANGES ==================== * New and modified GDB server monitor features: |
|
From: Mark W. <ma...@so...> - 2020-05-02 14:31:43
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=aaebe6aa08f09baed68e085da9a8ddaf3ae96227 commit aaebe6aa08f09baed68e085da9a8ddaf3ae96227 Author: Mark Wielaard <ma...@kl...> Date: Sat May 2 16:12:21 2020 +0200 Mention exp-sgcheck removal in NEWS. Diff: --- NEWS | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/NEWS b/NEWS index 04effd80d4..5179c7f894 100644 --- a/NEWS +++ b/NEWS @@ -62,6 +62,15 @@ support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. valgrind will now produce a warning to say the suppression entry will not work, and suggest the needed change. +* exp-sgcheck: + + - The exprimental Stack and Global Array Checking tool has been removed. + It only ever worked on x86 and amd64, and even on those it had a + high false positive rate and was slow. An alternative for detecting + stack and global array overruns is using the AddressSanitizer (ASAN) + facility of the GCC and llvm compilers which require you to rebuild + your code with -fsanitize=address. + * ==================== OTHER CHANGES ==================== * New and modified GDB server monitor features: |
|
From: Mark W. <ma...@so...> - 2020-05-02 14:26:05
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=d772e25995c3400eecf2b6070e0bf3411447c3d1 commit d772e25995c3400eecf2b6070e0bf3411447c3d1 Author: Mark Wielaard <ma...@kl...> Date: Sat May 2 16:21:44 2020 +0200 Remove SGcheck from documentation. Since the SGcheck tool was removed for 3.16.0, also remove it from the manual intro and core sections and the xml-output-protocol4 description. Diff: --- docs/internals/xml-output-protocol4.txt | 49 ++++----------------------------- docs/xml/manual-core.xml | 4 +-- docs/xml/manual-intro.xml | 7 ----- 3 files changed, 7 insertions(+), 53 deletions(-) diff --git a/docs/internals/xml-output-protocol4.txt b/docs/internals/xml-output-protocol4.txt index 3703bbd025..461b8a5044 100644 --- a/docs/internals/xml-output-protocol4.txt +++ b/docs/internals/xml-output-protocol4.txt @@ -4,7 +4,7 @@ 14 October 2011 Protocols 1 through 3 supported Memcheck only. Protocol 4 provides -XML output for Memcheck, Helgrind, DRD and SGcheck. Technically there +XML output for Memcheck, Helgrind and DRD. Technically there are four variants of Protocol 4, one for each tool, since they produce different errors. The four variants differ only in the definition of the ERROR nonterminal and are otherwise identical. @@ -81,7 +81,7 @@ XWHAT, and between AUXWHAT and XAUXWHAT. The definition of Protocol 4 now follows. It is structured similarly to that of the previous protocols, except that there is a separate definition of a nonterminal called TOOLSPECIFIC for each of Memcheck, -Helgrind, DRD and SGcheck. The XWHAT and XAUXWHAT nonterminals also +Helgrind and DRD. The XWHAT and XAUXWHAT nonterminals also have tool-specific components. Apart from that, the structure is common to all supported tools. @@ -199,9 +199,9 @@ the following in sequence: </status> * Zero or more of (either ERRORCOUNTS or TOOLSPECIFIC). In Memcheck's - case these will be complaints from the leak checker. For SGcheck - and Helgrind we don't expect any output here (but the spec does not - guarantee that either). + case these will be complaints from the leak checker. For Helgrind + we don't expect any output here (but the spec does not guarantee that + either). * SUPPCOUNTS, indicating how many times each suppression was used. @@ -571,45 +571,6 @@ The possible values are: indicating probable integer overflow or cast from negative signed -==================================================================== - -TOOLSPECIFIC definition for SGcheck ------------------------------------ - -For SGcheck, a TOOLSPECIFIC is simply an ERROR: - -TOOLSPECIFIC = ERROR - - -ERROR details for SGcheck -------------------------- - -SGcheck does not produce any XWHAT records, despite the fact that -"ERROR definition -- common structure" says that tools may do so. - - -XAUXWHATs (for definition, see above) may contain the following extra -components (along with the mandatory <text>...</text> component): - -* <file>TEXT</file>, as defined in FRAME - -* <line>INT</line>, as defined in FRAME - -* <dir>TEXT</dir>, as defined in FRAME - - -KIND for SGcheck ----------------- -This is a small enumeration indicating roughly the nature of an error. -The possible values are: - - SorG - - Stack or global array inconsistency (roughly speaking, an - overrun of a stack or global array). The <auxwhat> blocks give - further details. - - ==================================================================== TOOLSPECIFIC definition for Helgrind diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml index 72730ec7bb..50904ff82a 100644 --- a/docs/xml/manual-core.xml +++ b/docs/xml/manual-core.xml @@ -995,8 +995,8 @@ that can report errors, e.g. Memcheck, but not Cachegrind.</para> <para>This option is aimed at making life easier for tools that consume Valgrind's output as input, such as GUI front ends. Currently this - option works with Memcheck, Helgrind, DRD and SGcheck. The output - format is specified in the file + option works with Memcheck, Helgrind and DRD. The output format is + specified in the file <computeroutput>docs/internals/xml-output-protocol4.txt</computeroutput> in the source tree for Valgrind 3.5.0 or later.</para> diff --git a/docs/xml/manual-intro.xml b/docs/xml/manual-intro.xml index 79351ba18b..6f730d1ac0 100644 --- a/docs/xml/manual-intro.xml +++ b/docs/xml/manual-intro.xml @@ -59,13 +59,6 @@ and without disturbing the existing structure.</para> block utilisation, and layout inefficiencies.</para> </listitem> - <listitem> - <para><command>SGcheck</command> is an experimental tool that can - detect overruns of stack and global arrays. Its functionality is - complementary to that of Memcheck: SGcheck finds problems that - Memcheck can't, and vice versa..</para> - </listitem> - <listitem> <para><command>BBV</command> is an experimental SimPoint basic block vector generator. It is useful to people doing computer architecture |
|
From: Mark W. <ma...@so...> - 2020-05-02 14:13:35
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=bbb629a5682bc27a4615587595583dc0cb604c17 commit bbb629a5682bc27a4615587595583dc0cb604c17 Author: Mark Wielaard <ma...@kl...> Date: Sat May 2 15:52:43 2020 +0200 Remove exp-sgcheck from .gitignore. commit 40187fcd6 removed the exp-sgcheck tool. Also remove it from .gitignore. Reported-by: Paul FLOYD <pj...@wa...> Diff: --- .gitignore | 65 -------------------------------------------------------------- 1 file changed, 65 deletions(-) diff --git a/.gitignore b/.gitignore index 4c2b4fd5b6..085a30b4ad 100644 --- a/.gitignore +++ b/.gitignore @@ -527,71 +527,6 @@ /exp-bbv/tests/x86-linux/Makefile /exp-bbv/tests/x86-linux/Makefile.in -# /exp-sgcheck/ -/exp-sgcheck/*.dSYM -/exp-sgcheck/.deps -/exp-sgcheck/exp-sgcheck-*-darwin -/exp-sgcheck/exp-sgcheck-*-linux -/exp-sgcheck/exp-sgcheck-*-solaris -/exp-sgcheck/Makefile -/exp-sgcheck/Makefile.in -/exp-sgcheck/preen_invars -/exp-sgcheck/vgpreload_exp-ptrcheck-*-linux.so -/exp-sgcheck/vgpreload_exp-ptrcheck-*-darwin.so -/exp-sgcheck/vgpreload_exp-ptrcheck-*-darwin.so.dSYM -/exp-sgcheck/vgpreload_exp-sgcheck-*-darwin.so -/exp-sgcheck/vgpreload_exp-sgcheck-*-linux.so -/exp-sgcheck/vgpreload_exp-sgcheck-*-solaris.so - -# /exp-sgcheck/docs/ -/exp-sgcheck/docs/Makefile -/exp-sgcheck/docs/Makefile.in - -# /exp-sgcheck/tests/ -/exp-sgcheck/tests/*.dSYM -/exp-sgcheck/tests/*.out -/exp-sgcheck/tests/*.so -/exp-sgcheck/tests/*.stderr.diff* -/exp-sgcheck/tests/*.stdout.diff* -/exp-sgcheck/tests/.deps -/exp-sgcheck/tests/Makefile -/exp-sgcheck/tests/Makefile.in -/exp-sgcheck/tests/add -/exp-sgcheck/tests/and -/exp-sgcheck/tests/arith -/exp-sgcheck/tests/bad_percentify -/exp-sgcheck/tests/base -/exp-sgcheck/tests/ccc -/exp-sgcheck/tests/cmp -/exp-sgcheck/tests/fp -/exp-sgcheck/tests/globalerr -/exp-sgcheck/tests/hackedbz2 -/exp-sgcheck/tests/hp_bounds -/exp-sgcheck/tests/hp_dangle -/exp-sgcheck/tests/hsg -/exp-sgcheck/tests/idiv -/exp-sgcheck/tests/imul -/exp-sgcheck/tests/justify -/exp-sgcheck/tests/mm -/exp-sgcheck/tests/neg -/exp-sgcheck/tests/not -/exp-sgcheck/tests/or -/exp-sgcheck/tests/partial -/exp-sgcheck/tests/preen_invars -/exp-sgcheck/tests/pth_create -/exp-sgcheck/tests/pth_specific -/exp-sgcheck/tests/realloc -/exp-sgcheck/tests/stackerr -/exp-sgcheck/tests/strcpy -/exp-sgcheck/tests/strlen -/exp-sgcheck/tests/sub -/exp-sgcheck/tests/supp -/exp-sgcheck/tests/syscall -/exp-sgcheck/tests/tricky -/exp-sgcheck/tests/unaligned -/exp-sgcheck/tests/xor -/exp-sgcheck/tests/zero - # /gdbserver_tests/ /gdbserver_tests/*.dSYM /gdbserver_tests/*.diff* |
|
From: Mark W. <ma...@so...> - 2020-05-02 14:13:21
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=bbb629a5682bc27a4615587595583dc0cb604c17 commit bbb629a5682bc27a4615587595583dc0cb604c17 Author: Mark Wielaard <ma...@kl...> Date: Sat May 2 15:52:43 2020 +0200 Remove exp-sgcheck from .gitignore. commit 40187fcd6 removed the exp-sgcheck tool. Also remove it from .gitignore. Reported-by: Paul FLOYD <pj...@wa...> Diff: --- .gitignore | 65 -------------------------------------------------------------- 1 file changed, 65 deletions(-) diff --git a/.gitignore b/.gitignore index 4c2b4fd5b6..085a30b4ad 100644 --- a/.gitignore +++ b/.gitignore @@ -527,71 +527,6 @@ /exp-bbv/tests/x86-linux/Makefile /exp-bbv/tests/x86-linux/Makefile.in -# /exp-sgcheck/ -/exp-sgcheck/*.dSYM -/exp-sgcheck/.deps -/exp-sgcheck/exp-sgcheck-*-darwin -/exp-sgcheck/exp-sgcheck-*-linux -/exp-sgcheck/exp-sgcheck-*-solaris -/exp-sgcheck/Makefile -/exp-sgcheck/Makefile.in -/exp-sgcheck/preen_invars -/exp-sgcheck/vgpreload_exp-ptrcheck-*-linux.so -/exp-sgcheck/vgpreload_exp-ptrcheck-*-darwin.so -/exp-sgcheck/vgpreload_exp-ptrcheck-*-darwin.so.dSYM -/exp-sgcheck/vgpreload_exp-sgcheck-*-darwin.so -/exp-sgcheck/vgpreload_exp-sgcheck-*-linux.so -/exp-sgcheck/vgpreload_exp-sgcheck-*-solaris.so - -# /exp-sgcheck/docs/ -/exp-sgcheck/docs/Makefile -/exp-sgcheck/docs/Makefile.in - -# /exp-sgcheck/tests/ -/exp-sgcheck/tests/*.dSYM -/exp-sgcheck/tests/*.out -/exp-sgcheck/tests/*.so -/exp-sgcheck/tests/*.stderr.diff* -/exp-sgcheck/tests/*.stdout.diff* -/exp-sgcheck/tests/.deps -/exp-sgcheck/tests/Makefile -/exp-sgcheck/tests/Makefile.in -/exp-sgcheck/tests/add -/exp-sgcheck/tests/and -/exp-sgcheck/tests/arith -/exp-sgcheck/tests/bad_percentify -/exp-sgcheck/tests/base -/exp-sgcheck/tests/ccc -/exp-sgcheck/tests/cmp -/exp-sgcheck/tests/fp -/exp-sgcheck/tests/globalerr -/exp-sgcheck/tests/hackedbz2 -/exp-sgcheck/tests/hp_bounds -/exp-sgcheck/tests/hp_dangle -/exp-sgcheck/tests/hsg -/exp-sgcheck/tests/idiv -/exp-sgcheck/tests/imul -/exp-sgcheck/tests/justify -/exp-sgcheck/tests/mm -/exp-sgcheck/tests/neg -/exp-sgcheck/tests/not -/exp-sgcheck/tests/or -/exp-sgcheck/tests/partial -/exp-sgcheck/tests/preen_invars -/exp-sgcheck/tests/pth_create -/exp-sgcheck/tests/pth_specific -/exp-sgcheck/tests/realloc -/exp-sgcheck/tests/stackerr -/exp-sgcheck/tests/strcpy -/exp-sgcheck/tests/strlen -/exp-sgcheck/tests/sub -/exp-sgcheck/tests/supp -/exp-sgcheck/tests/syscall -/exp-sgcheck/tests/tricky -/exp-sgcheck/tests/unaligned -/exp-sgcheck/tests/xor -/exp-sgcheck/tests/zero - # /gdbserver_tests/ /gdbserver_tests/*.dSYM /gdbserver_tests/*.diff* |
|
From: Carl L. <ce...@us...> - 2020-05-02 05:36:14
|
Valgrind developers:
I pulled down the 3.16 branch and ran the regression tests on Power 7,
Power 8 and Power 9 to see where things stand. I also pulled down the
3.15 branch and ran it as well to see what has changed since the last
release. Things look good at this point.
Power 7
679 tests, 11 stderr failures, 3 stdout failures,
0 stderrB failures, 1 stdoutB failure, 0 post failures
gdbserver_tests/hgtls (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
drd/tests/annotate_ignore_read (stderr)
drd/tests/annotate_order_1 (stderr)
drd/tests/annotate_order_2 (stderr)
drd/tests/annotate_order_3 (stderr)
drd/tests/annotate_spinlock (stderr)
drd/tests/std_mutex (stderr) new failure in 3.16
drd/tests/std_thread (stderr)
drd/tests/std_thread2 (stderr)
none/tests/linux/clonev (stdout)
none/tests/linux/clonev (stderr)
none/tests/ppc32/power5+_round (stdout)
none/tests/ppc32/testVMX (stdout)
Power 8
652 tests, 4 stderr failures, 0 stdout failures,
0 stderrB failures, 2 stdoutB failures, 2 post failures
gdbserver_tests/nlgone_abrt (stdoutB)
gdbserver_tests/nlpasssigalrm (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/linux/rfcomm (stderr)
memcheck/tests/linux/sys-preadv2_pwritev2 (stderr) new failure in 3.16
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
none/tests/fdleak_ipv4 (stderr)
Power 9
652 tests, 3 stderr failures, 0 stdout failures,
0 stderrB failures, 1 stdoutB failure, 2 post failures
gdbserver_tests/nlcontrolc (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/linux/rfcomm (stderr)
memcheck/tests/linux/sys-preadv2_pwritev2 (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
The results are identical to the 3.15 results
Relative to the last result we only have two new failures. I find the
new failure on Power 8 a bit interesting as it didn't fail on 3.15 but
it does fail on Power 9 for both releases.
I have not had time yet to look into the new failures but will look
into them. I don't see any blocking issues for the 3.16 release for
the Power platform based on these results.
Carl Love
|
|
From: Paul F. <pj...@wa...> - 2020-05-01 16:12:58
|
Looks good One little request - could someone please remove exp-sgcheck from .gitignore? A+ Paul |
|
From: Mark W. <ma...@kl...> - 2020-05-01 15:16:36
|
Hi, On Mon, Apr 27, 2020 at 03:36:57PM +0200, Julian Seward wrote: > Unfortunately the previous plan dated 5 Feb 2020 didn't work out, partly due > to lack of time and partly because various architectures (MIPS, s390 and > POWER) were still broken by the "grail" (&&-recovery) changes that landed at > the start of the year. > > The situation has now improved. All architectures now work again -- a big > thank-you to the port maintainers for fixing them. However, available time > remains scarce, and the need to freeze and ship has increased. As the trunk > seems in a fairly good state right now, the revised plan is as follows: at the > end of day, UTC+2, Weds 29 April, a 3.16 branch will be made from the trunk. > Then there will be a two week stabilisation period, so that the release will > be made on 14 May. > > Once the branch has been made, we can cherry pick low-risk and/or important > fixes that land on the trunk after the branching, providing there is a > reasonable case for them. To celebrate that we have a branch now and to make it easier for people to test I created Fedora rawhide and copr packages from the current VALGRIND_3_16_BRANCH git branch: https://koji.fedoraproject.org/koji/buildinfo?buildID=1500383 (aarch64, armv7hl, i686, ppc64le, s390x, x86_64) https://copr.fedorainfracloud.org/coprs/mjw/valgrind-3.16.0/ (Epel for CentOS 7, aarch64 and x86_64 Epel for CentOS 8, aarch64 and x86_64 Fedora 30, aarch64, i386 and x86_64 Fedora 31, aarch64 and x86_64 Fedora 32, aarch64 and x86_64) A quick check of the test results make it look like we have a pretty good branch already. Cheers, Mark |