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
(4) |
2
(2) |
|
3
(1) |
4
(1) |
5
|
6
|
7
|
8
(1) |
9
(1) |
|
10
(4) |
11
(1) |
12
(2) |
13
(2) |
14
(3) |
15
(2) |
16
(2) |
|
17
|
18
(1) |
19
(5) |
20
|
21
|
22
(8) |
23
(4) |
|
24
(1) |
25
|
26
(3) |
27
(8) |
28
(4) |
29
(4) |
30
(1) |
|
From: Philippe W. <phi...@so...> - 2017-09-22 21:52:59
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f053756e2880dbb7291aac086aa48e1fd3b6f812 commit f053756e2880dbb7291aac086aa48e1fd3b6f812 Author: Philippe Waroquiers <phi...@sk...> Date: Fri Sep 22 23:50:35 2017 +0200 Follow up to 345307 - Warning about "still reachable" memory when using libstdc++ from gcc 5 The bug itself was solved in 3.12 by the addition of __gnu_cxx::__freeres in the libstdc++ and have valgrind calling it before exit. However, depending on the version of the libstdc++, the test leak_cpp_interior was giving different results. This commit adds some filtering specific to the test, so as to not depend anymore of the absolute number of bytes leaked, and adds a suppression entry to ignore the memory allocated by libstdc++. This allows to have only 2 .exp files, instead of 4 (or worse, if we would have to handle yet other .exp files depending on the libstdc++ version). Diff: --- memcheck/tests/Makefile.am | 2 +- memcheck/tests/filter_leak_cpp_interior | 13 ++ memcheck/tests/leak_cpp_interior.stderr.exp | 111 ++++++++-------- memcheck/tests/leak_cpp_interior.stderr.exp-64bit | 111 ++++++++-------- .../leak_cpp_interior.stderr.exp-64bit-solaris | 142 --------------------- .../tests/leak_cpp_interior.stderr.exp-solaris | 142 --------------------- memcheck/tests/leak_cpp_interior.vgtest | 3 +- memcheck/tests/libstdc++.supp | 75 +++++++++++ 8 files changed, 193 insertions(+), 406 deletions(-) diff --git a/memcheck/tests/Makefile.am b/memcheck/tests/Makefile.am index b8529f6..b9ba67b 100644 --- a/memcheck/tests/Makefile.am +++ b/memcheck/tests/Makefile.am @@ -64,6 +64,7 @@ dist_noinst_SCRIPTS = \ filter_allocs \ filter_dw4 \ filter_leak_cases_possible \ + filter_leak_cpp_interior \ filter_stderr filter_xml \ filter_strchr \ filter_varinfo3 \ @@ -114,7 +115,6 @@ EXTRA_DIST = \ cond_st.stderr.exp-64bit-non-arm \ cond_st.stderr.exp-32bit-non-arm \ leak_cpp_interior.stderr.exp leak_cpp_interior.stderr.exp-64bit leak_cpp_interior.vgtest \ - leak_cpp_interior.stderr.exp-solaris leak_cpp_interior.stderr.exp-64bit-solaris \ custom_alloc.stderr.exp custom_alloc.vgtest \ custom_alloc.stderr.exp-s390x-mvc \ custom-overlap.stderr.exp custom-overlap.vgtest \ diff --git a/memcheck/tests/filter_leak_cpp_interior b/memcheck/tests/filter_leak_cpp_interior new file mode 100755 index 0000000..ae09087 --- /dev/null +++ b/memcheck/tests/filter_leak_cpp_interior @@ -0,0 +1,13 @@ +#! /bin/sh +# +# Remove the suppressed line and the total heap usage line. +# Replace the absolute number of bytes different of 0 by x. +./filter_stderr "$@" | + sed -e '/ suppressed:/d'\ + -e '/ total heap usage:/d'\ + -e 's/[1-9][0-9,]* bytes/x bytes/' \ + -e 's/[1-9][0-9,]* (\([+-]\)[1-9][0-9,]*) bytes/x (\1x) bytes/' \ + -e 's/0 (\([+-]\)[1-9][0-9,]*) bytes/0 (\1x) bytes/' \ + -e 's/[1-9][0-9,]* (\([+-]\)0) bytes/x (\10) bytes/' + + diff --git a/memcheck/tests/leak_cpp_interior.stderr.exp b/memcheck/tests/leak_cpp_interior.stderr.exp index 70e2764..df6cad2 100644 --- a/memcheck/tests/leak_cpp_interior.stderr.exp +++ b/memcheck/tests/leak_cpp_interior.stderr.exp @@ -1,118 +1,110 @@ valgrind output will go to log VALGRIND_DO_LEAK_CHECK -4 bytes in 1 blocks are definitely lost in loss record ... of ... +x bytes in 1 blocks are definitely lost in loss record ... of ... by 0x........: doit() (leak_cpp_interior.cpp:116) by 0x........: main (leak_cpp_interior.cpp:131) LEAK SUMMARY: - definitely lost: 4 bytes in 1 blocks + definitely lost: x bytes in 1 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks - still reachable: 163 bytes in 8 blocks + still reachable: x bytes in 8 blocks of which reachable via heuristic: - stdstring : 56 bytes in 2 blocks - length64 : 31 bytes in 1 blocks - newarray : 28 bytes in 1 blocks - multipleinheritance: 24 bytes in 2 blocks - suppressed: 0 bytes in 0 blocks + stdstring : x bytes in 2 blocks + length64 : x bytes in 1 blocks + newarray : x bytes in 1 blocks + multipleinheritance: x bytes in 2 blocks Reachable blocks (those to which a pointer was found) are not shown. To see them, rerun with: --leak-check=full --show-leak-kinds=all leak_check summary heuristics multipleinheritance LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 115 (+115) bytes in 4 (+4) blocks - still reachable: 48 (-115) bytes in 4 (-4) blocks + possibly lost: x (+x) bytes in 4 (+4) blocks + still reachable: x (-x) bytes in 4 (-4) blocks of which reachable via heuristic: - stdstring : 0 (-56) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-28) bytes in 0 (-1) blocks - multipleinheritance: 24 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : 0 (-x) bytes in 0 (-2) blocks + length64 : 0 (-x) bytes in 0 (-1) blocks + newarray : 0 (-x) bytes in 0 (-1) blocks + multipleinheritance: x (+0) bytes in 2 (+0) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary any heuristics newarray LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 111 (-4) bytes in 5 (+1) blocks - still reachable: 52 (+4) bytes in 3 (-1) blocks + possibly lost: x (-x) bytes in 5 (+1) blocks + still reachable: x (+x) bytes in 3 (-1) blocks of which reachable via heuristic: - newarray : 28 (+28) bytes in 1 (+1) blocks - multipleinheritance: 0 (-24) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + newarray : x (+x) bytes in 1 (+1) blocks + multipleinheritance: 0 (-x) bytes in 0 (-2) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics length64 LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 108 (-3) bytes in 5 (+0) blocks - still reachable: 55 (+3) bytes in 3 (+0) blocks + possibly lost: x (-x) bytes in 5 (+0) blocks + still reachable: x (+x) bytes in 3 (+0) blocks of which reachable via heuristic: - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 0 (-28) bytes in 0 (-1) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + length64 : x (+x) bytes in 1 (+1) blocks + newarray : 0 (-x) bytes in 0 (-1) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics stdstring LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 83 (-25) bytes in 4 (-1) blocks - still reachable: 80 (+25) bytes in 4 (+1) blocks + possibly lost: x (-x) bytes in 4 (-1) blocks + still reachable: x (+x) bytes in 4 (+1) blocks of which reachable via heuristic: - stdstring : 56 (+56) bytes in 2 (+2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : x (+x) bytes in 2 (+2) blocks + length64 : 0 (-x) bytes in 0 (-1) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics multipleinheritance,newarray,stdstring,length64 LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 0 (-83) bytes in 0 (-4) blocks - still reachable: 163 (+83) bytes in 8 (+4) blocks + possibly lost: 0 (-x) bytes in 0 (-4) blocks + still reachable: x (+x) bytes in 8 (+4) blocks of which reachable via heuristic: - stdstring : 56 (+0) bytes in 2 (+0) blocks - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 28 (+28) bytes in 1 (+1) blocks - multipleinheritance: 24 (+24) bytes in 2 (+2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : x (+0) bytes in 2 (+0) blocks + length64 : x (+x) bytes in 1 (+1) blocks + newarray : x (+x) bytes in 1 (+1) blocks + multipleinheritance: x (+x) bytes in 2 (+2) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics all LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks possibly lost: 0 (+0) bytes in 0 (+0) blocks - still reachable: 163 (+0) bytes in 8 (+0) blocks + still reachable: x (+0) bytes in 8 (+0) blocks of which reachable via heuristic: - stdstring : 56 (+0) bytes in 2 (+0) blocks - length64 : 31 (+0) bytes in 1 (+0) blocks - newarray : 28 (+0) bytes in 1 (+0) blocks - multipleinheritance: 24 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : x (+0) bytes in 2 (+0) blocks + length64 : x (+0) bytes in 1 (+0) blocks + newarray : x (+0) bytes in 1 (+0) blocks + multipleinheritance: x (+0) bytes in 2 (+0) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics none LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 139 (+139) bytes in 6 (+6) blocks - still reachable: 24 (-139) bytes in 2 (-6) blocks + possibly lost: x (+x) bytes in 6 (+6) blocks + still reachable: x (-x) bytes in 2 (-6) blocks of which reachable via heuristic: - stdstring : 0 (-56) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-28) bytes in 0 (-1) blocks - multipleinheritance: 0 (-24) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : 0 (-x) bytes in 0 (-2) blocks + length64 : 0 (-x) bytes in 0 (-1) blocks + newarray : 0 (-x) bytes in 0 (-1) blocks + multipleinheritance: 0 (-x) bytes in 0 (-2) blocks To see details of leaked memory, give 'full' arg to leak_check -Searching for pointers pointing in 20 bytes from 0x........ -*0x........ interior points at 4 bytes inside 0x........ +Searching for pointers pointing in x bytes from 0x........ +*0x........ interior points at x bytes inside 0x........ Address 0x........ is 0 bytes inside data symbol "ptr" block at 0x........ considered reachable by ptr 0x........ using newarray heuristic destruct MyClass @@ -134,7 +126,6 @@ Finished! HEAP SUMMARY: in use at exit: 0 bytes in 0 blocks - total heap usage: 9 allocs, 9 frees, 167 bytes allocated All heap blocks were freed -- no leaks are possible diff --git a/memcheck/tests/leak_cpp_interior.stderr.exp-64bit b/memcheck/tests/leak_cpp_interior.stderr.exp-64bit index 612fa3e..3899730 100644 --- a/memcheck/tests/leak_cpp_interior.stderr.exp-64bit +++ b/memcheck/tests/leak_cpp_interior.stderr.exp-64bit @@ -1,118 +1,110 @@ valgrind output will go to log VALGRIND_DO_LEAK_CHECK -8 bytes in 1 blocks are definitely lost in loss record ... of ... +x bytes in 1 blocks are definitely lost in loss record ... of ... by 0x........: doit() (leak_cpp_interior.cpp:116) by 0x........: main (leak_cpp_interior.cpp:131) LEAK SUMMARY: - definitely lost: 8 bytes in 1 blocks + definitely lost: x bytes in 1 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks - still reachable: 239 bytes in 8 blocks + still reachable: x bytes in 8 blocks of which reachable via heuristic: - stdstring : 80 bytes in 2 blocks - length64 : 31 bytes in 1 blocks - newarray : 32 bytes in 1 blocks - multipleinheritance: 48 bytes in 2 blocks - suppressed: 0 bytes in 0 blocks + stdstring : x bytes in 2 blocks + length64 : x bytes in 1 blocks + newarray : x bytes in 1 blocks + multipleinheritance: x bytes in 2 blocks Reachable blocks (those to which a pointer was found) are not shown. To see them, rerun with: --leak-check=full --show-leak-kinds=all leak_check summary heuristics multipleinheritance LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 143 (+143) bytes in 4 (+4) blocks - still reachable: 96 (-143) bytes in 4 (-4) blocks + possibly lost: x (+x) bytes in 4 (+4) blocks + still reachable: x (-x) bytes in 4 (-4) blocks of which reachable via heuristic: - stdstring : 0 (-80) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-32) bytes in 0 (-1) blocks - multipleinheritance: 48 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : 0 (-x) bytes in 0 (-2) blocks + length64 : 0 (-x) bytes in 0 (-1) blocks + newarray : 0 (-x) bytes in 0 (-1) blocks + multipleinheritance: x (+0) bytes in 2 (+0) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary any heuristics newarray LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 128 (-15) bytes in 4 (+0) blocks - still reachable: 111 (+15) bytes in 4 (+0) blocks + possibly lost: x (-x) bytes in 4 (+0) blocks + still reachable: x (+x) bytes in 4 (+0) blocks of which reachable via heuristic: - newarray : 63 (+63) bytes in 2 (+2) blocks - multipleinheritance: 0 (-48) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + newarray : x (+x) bytes in 2 (+2) blocks + multipleinheritance: 0 (-x) bytes in 0 (-2) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics length64 LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 160 (+32) bytes in 5 (+1) blocks - still reachable: 79 (-32) bytes in 3 (-1) blocks + possibly lost: x (+x) bytes in 5 (+1) blocks + still reachable: x (-x) bytes in 3 (-1) blocks of which reachable via heuristic: - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 0 (-63) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + length64 : x (+x) bytes in 1 (+1) blocks + newarray : 0 (-x) bytes in 0 (-2) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics stdstring LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 111 (-49) bytes in 4 (-1) blocks - still reachable: 128 (+49) bytes in 4 (+1) blocks + possibly lost: x (-x) bytes in 4 (-1) blocks + still reachable: x (+x) bytes in 4 (+1) blocks of which reachable via heuristic: - stdstring : 80 (+80) bytes in 2 (+2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : x (+x) bytes in 2 (+2) blocks + length64 : 0 (-x) bytes in 0 (-1) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics multipleinheritance,newarray,stdstring,length64 LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 0 (-111) bytes in 0 (-4) blocks - still reachable: 239 (+111) bytes in 8 (+4) blocks + possibly lost: 0 (-x) bytes in 0 (-4) blocks + still reachable: x (+x) bytes in 8 (+4) blocks of which reachable via heuristic: - stdstring : 80 (+0) bytes in 2 (+0) blocks - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 32 (+32) bytes in 1 (+1) blocks - multipleinheritance: 48 (+48) bytes in 2 (+2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : x (+0) bytes in 2 (+0) blocks + length64 : x (+x) bytes in 1 (+1) blocks + newarray : x (+x) bytes in 1 (+1) blocks + multipleinheritance: x (+x) bytes in 2 (+2) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics all LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks possibly lost: 0 (+0) bytes in 0 (+0) blocks - still reachable: 239 (+0) bytes in 8 (+0) blocks + still reachable: x (+0) bytes in 8 (+0) blocks of which reachable via heuristic: - stdstring : 80 (+0) bytes in 2 (+0) blocks - length64 : 31 (+0) bytes in 1 (+0) blocks - newarray : 32 (+0) bytes in 1 (+0) blocks - multipleinheritance: 48 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : x (+0) bytes in 2 (+0) blocks + length64 : x (+0) bytes in 1 (+0) blocks + newarray : x (+0) bytes in 1 (+0) blocks + multipleinheritance: x (+0) bytes in 2 (+0) blocks To see details of leaked memory, give 'full' arg to leak_check leak_check summary heuristics none LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks + definitely lost: x (+0) bytes in 1 (+0) blocks indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 191 (+191) bytes in 6 (+6) blocks - still reachable: 48 (-191) bytes in 2 (-6) blocks + possibly lost: x (+x) bytes in 6 (+6) blocks + still reachable: x (-x) bytes in 2 (-6) blocks of which reachable via heuristic: - stdstring : 0 (-80) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-32) bytes in 0 (-1) blocks - multipleinheritance: 0 (-48) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks + stdstring : 0 (-x) bytes in 0 (-2) blocks + length64 : 0 (-x) bytes in 0 (-1) blocks + newarray : 0 (-x) bytes in 0 (-1) blocks + multipleinheritance: 0 (-x) bytes in 0 (-2) blocks To see details of leaked memory, give 'full' arg to leak_check -Searching for pointers pointing in 20 bytes from 0x........ -*0x........ interior points at 8 bytes inside 0x........ +Searching for pointers pointing in x bytes from 0x........ +*0x........ interior points at x bytes inside 0x........ Address 0x........ is 0 bytes inside data symbol "ptr" block at 0x........ considered reachable by ptr 0x........ using newarray heuristic destruct MyClass @@ -134,7 +126,6 @@ Finished! HEAP SUMMARY: in use at exit: 0 bytes in 0 blocks - total heap usage: 9 allocs, 9 frees, 247 bytes allocated All heap blocks were freed -- no leaks are possible diff --git a/memcheck/tests/leak_cpp_interior.stderr.exp-64bit-solaris b/memcheck/tests/leak_cpp_interior.stderr.exp-64bit-solaris deleted file mode 100644 index f7e1a07..0000000 --- a/memcheck/tests/leak_cpp_interior.stderr.exp-64bit-solaris +++ /dev/null @@ -1,142 +0,0 @@ - -valgrind output will go to log -VALGRIND_DO_LEAK_CHECK -8 bytes in 1 blocks are definitely lost in loss record ... of ... - by 0x........: doit() (leak_cpp_interior.cpp:116) - by 0x........: main (leak_cpp_interior.cpp:131) - -LEAK SUMMARY: - definitely lost: 8 bytes in 1 blocks - indirectly lost: 0 bytes in 0 blocks - possibly lost: 0 bytes in 0 blocks - still reachable: 273 bytes in 8 blocks - of which reachable via heuristic: - stdstring : 114 bytes in 2 blocks - length64 : 31 bytes in 1 blocks - newarray : 32 bytes in 1 blocks - multipleinheritance: 48 bytes in 2 blocks - suppressed: 0 bytes in 0 blocks -Reachable blocks (those to which a pointer was found) are not shown. -To see them, rerun with: --leak-check=full --show-leak-kinds=all - -leak_check summary heuristics multipleinheritance -LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 177 (+177) bytes in 4 (+4) blocks - still reachable: 96 (-177) bytes in 4 (-4) blocks - of which reachable via heuristic: - stdstring : 0 (-114) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-32) bytes in 0 (-1) blocks - multipleinheritance: 48 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary any heuristics newarray -LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 162 (-15) bytes in 4 (+0) blocks - still reachable: 111 (+15) bytes in 4 (+0) blocks - of which reachable via heuristic: - newarray : 63 (+63) bytes in 2 (+2) blocks - multipleinheritance: 0 (-48) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics length64 -LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 194 (+32) bytes in 5 (+1) blocks - still reachable: 79 (-32) bytes in 3 (-1) blocks - of which reachable via heuristic: - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 0 (-63) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics stdstring -LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 111 (-83) bytes in 4 (-1) blocks - still reachable: 162 (+83) bytes in 4 (+1) blocks - of which reachable via heuristic: - stdstring : 114 (+114) bytes in 2 (+2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics multipleinheritance,newarray,stdstring,length64 -LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 0 (-111) bytes in 0 (-4) blocks - still reachable: 273 (+111) bytes in 8 (+4) blocks - of which reachable via heuristic: - stdstring : 114 (+0) bytes in 2 (+0) blocks - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 32 (+32) bytes in 1 (+1) blocks - multipleinheritance: 48 (+48) bytes in 2 (+2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics all -LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 0 (+0) bytes in 0 (+0) blocks - still reachable: 273 (+0) bytes in 8 (+0) blocks - of which reachable via heuristic: - stdstring : 114 (+0) bytes in 2 (+0) blocks - length64 : 31 (+0) bytes in 1 (+0) blocks - newarray : 32 (+0) bytes in 1 (+0) blocks - multipleinheritance: 48 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics none -LEAK SUMMARY: - definitely lost: 8 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 225 (+225) bytes in 6 (+6) blocks - still reachable: 48 (-225) bytes in 2 (-6) blocks - of which reachable via heuristic: - stdstring : 0 (-114) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-32) bytes in 0 (-1) blocks - multipleinheritance: 0 (-48) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -Searching for pointers pointing in 20 bytes from 0x........ -*0x........ interior points at 8 bytes inside 0x........ - Address 0x........ is 0 bytes inside data symbol "ptr" -block at 0x........ considered reachable by ptr 0x........ using newarray heuristic -destruct MyClass -destruct MyClass -destruct MyClass -destruct Ce -destruct Be -destruct Ae -destruct Ce -destruct Be -destruct Ae -destruct C -destruct B -destruct A -destruct C -destruct B -destruct A -Finished! - -HEAP SUMMARY: - in use at exit: 0 bytes in 0 blocks - total heap usage: 9 allocs, 9 frees, 281 bytes allocated - -All heap blocks were freed -- no leaks are possible - -For counts of detected and suppressed errors, rerun with: -v -ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) diff --git a/memcheck/tests/leak_cpp_interior.stderr.exp-solaris b/memcheck/tests/leak_cpp_interior.stderr.exp-solaris deleted file mode 100644 index f9fc390..0000000 --- a/memcheck/tests/leak_cpp_interior.stderr.exp-solaris +++ /dev/null @@ -1,142 +0,0 @@ - -valgrind output will go to log -VALGRIND_DO_LEAK_CHECK -4 bytes in 1 blocks are definitely lost in loss record ... of ... - by 0x........: doit() (leak_cpp_interior.cpp:116) - by 0x........: main (leak_cpp_interior.cpp:131) - -LEAK SUMMARY: - definitely lost: 4 bytes in 1 blocks - indirectly lost: 0 bytes in 0 blocks - possibly lost: 0 bytes in 0 blocks - still reachable: 197 bytes in 8 blocks - of which reachable via heuristic: - stdstring : 90 bytes in 2 blocks - length64 : 31 bytes in 1 blocks - newarray : 28 bytes in 1 blocks - multipleinheritance: 24 bytes in 2 blocks - suppressed: 0 bytes in 0 blocks -Reachable blocks (those to which a pointer was found) are not shown. -To see them, rerun with: --leak-check=full --show-leak-kinds=all - -leak_check summary heuristics multipleinheritance -LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 149 (+149) bytes in 4 (+4) blocks - still reachable: 48 (-149) bytes in 4 (-4) blocks - of which reachable via heuristic: - stdstring : 0 (-90) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-28) bytes in 0 (-1) blocks - multipleinheritance: 24 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary any heuristics newarray -LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 145 (-4) bytes in 5 (+1) blocks - still reachable: 52 (+4) bytes in 3 (-1) blocks - of which reachable via heuristic: - newarray : 28 (+28) bytes in 1 (+1) blocks - multipleinheritance: 0 (-24) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics length64 -LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 142 (-3) bytes in 5 (+0) blocks - still reachable: 55 (+3) bytes in 3 (+0) blocks - of which reachable via heuristic: - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 0 (-28) bytes in 0 (-1) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics stdstring -LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 83 (-59) bytes in 4 (-1) blocks - still reachable: 114 (+59) bytes in 4 (+1) blocks - of which reachable via heuristic: - stdstring : 90 (+90) bytes in 2 (+2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics multipleinheritance,newarray,stdstring,length64 -LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 0 (-83) bytes in 0 (-4) blocks - still reachable: 197 (+83) bytes in 8 (+4) blocks - of which reachable via heuristic: - stdstring : 90 (+0) bytes in 2 (+0) blocks - length64 : 31 (+31) bytes in 1 (+1) blocks - newarray : 28 (+28) bytes in 1 (+1) blocks - multipleinheritance: 24 (+24) bytes in 2 (+2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics all -LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 0 (+0) bytes in 0 (+0) blocks - still reachable: 197 (+0) bytes in 8 (+0) blocks - of which reachable via heuristic: - stdstring : 90 (+0) bytes in 2 (+0) blocks - length64 : 31 (+0) bytes in 1 (+0) blocks - newarray : 28 (+0) bytes in 1 (+0) blocks - multipleinheritance: 24 (+0) bytes in 2 (+0) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -leak_check summary heuristics none -LEAK SUMMARY: - definitely lost: 4 (+0) bytes in 1 (+0) blocks - indirectly lost: 0 (+0) bytes in 0 (+0) blocks - possibly lost: 173 (+173) bytes in 6 (+6) blocks - still reachable: 24 (-173) bytes in 2 (-6) blocks - of which reachable via heuristic: - stdstring : 0 (-90) bytes in 0 (-2) blocks - length64 : 0 (-31) bytes in 0 (-1) blocks - newarray : 0 (-28) bytes in 0 (-1) blocks - multipleinheritance: 0 (-24) bytes in 0 (-2) blocks - suppressed: 0 (+0) bytes in 0 (+0) blocks -To see details of leaked memory, give 'full' arg to leak_check - -Searching for pointers pointing in 20 bytes from 0x........ -*0x........ interior points at 4 bytes inside 0x........ - Address 0x........ is 0 bytes inside data symbol "ptr" -block at 0x........ considered reachable by ptr 0x........ using newarray heuristic -destruct MyClass -destruct MyClass -destruct MyClass -destruct Ce -destruct Be -destruct Ae -destruct Ce -destruct Be -destruct Ae -destruct C -destruct B -destruct A -destruct C -destruct B -destruct A -Finished! - -HEAP SUMMARY: - in use at exit: 0 bytes in 0 blocks - total heap usage: 9 allocs, 9 frees, 201 bytes allocated - -All heap blocks were freed -- no leaks are possible - -For counts of detected and suppressed errors, rerun with: -v -ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) diff --git a/memcheck/tests/leak_cpp_interior.vgtest b/memcheck/tests/leak_cpp_interior.vgtest index 4ecc219..2fed646 100644 --- a/memcheck/tests/leak_cpp_interior.vgtest +++ b/memcheck/tests/leak_cpp_interior.vgtest @@ -1,2 +1,3 @@ prog: leak_cpp_interior -vgopts: --leak-check=summary --leak-check-heuristics=multipleinheritance,stdstring,newarray,length64 +vgopts: --leak-check=summary --leak-check-heuristics=multipleinheritance,stdstring,newarray,length64 --suppressions=libstdc++.supp +stderr_filter: filter_leak_cpp_interior diff --git a/memcheck/tests/libstdc++.supp b/memcheck/tests/libstdc++.supp new file mode 100644 index 0000000..fad537f --- /dev/null +++ b/memcheck/tests/libstdc++.supp @@ -0,0 +1,75 @@ +# Below is a temporary patch (slightly modified) from +# 345307 - Warning about "still reachable" memory when using libstdc++ from gcc 5 +# This patch is not needed anymore if libstdc++ provides __gnu_cxx::__freeres +# but we still need to ignore these allocations during the leak_cpp_interior +# to have the test behaviour not depending on libstdc++ version. + + + +# Some programs are using the C++ STL and string classes. +# Valgrind reports 'still reachable' memory leaks involving these classes +# at the exit of the program, but there should be none. +# +# Many implementations of the C++ standard libraries use their own memory +# pool allocators. Memory for quite a number of destructed objects is not +# immediately freed and given back to the OS, but kept in the pool(s) for +# later re-use. The fact that the pools are not freed at the exit of the +# program cause Valgrind to report this memory as still reachable. +# +# The behavior not to free pools at the exit could be called a bug of the +# library though. +# +# Using GCC, you can force the STL to use malloc and to free memory as soon +# as possible by globally disabling memory caching. Beware! Doing so will +# probably slow down your program, sometimes drastically. +# +# There are other ways to disable memory pooling: using the malloc_alloc +# template with your objects (not portable, but should work for GCC) or +# even writing your own memory allocators. But beware: allocators belong +# to the more messy parts of the STL and people went to great lengths to +# make the STL portable across platforms. Chances are good that your +# solution will work on your platform, but not on others. +# +# 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1 +# at 0x4C28D06: malloc (vg_replace_malloc.c:299) +# by 0x50C317F: ??? (in /usr/lib64/libstdc++.so.6.0.21) +# by 0x400F759: call_init.part.0 (dl-init.c:72) +# by 0x400F86A: call_init (dl-init.c:30) +# by 0x400F86A: _dl_init (dl-init.c:120) +# by 0x4000CB9: ??? (in /usr/lib64/ld-2.22.so) +# +# HEAP SUMMARY: +# in use at exit: 72,704 bytes in 1 blocks +# total heap usage: 4 allocs, 3 frees, 72,864 bytes allocated +# +# LEAK SUMMARY: +# definitely lost: 0 bytes in 0 blocks +# indirectly lost: 0 bytes in 0 blocks +# possibly lost: 0 bytes in 0 blocks +# still reachable: 72,704 bytes in 1 blocks +# suppressed: 0 bytes in 0 blocks + +{ + malloc-leaks-cxx-stl-string-classes + Memcheck:Leak + match-leak-kinds: reachable + fun:malloc + obj:*lib*/libstdc++.so* + fun:call_init.part.0 + fun:call_init + fun:_dl_init + obj:*lib*/ld-2.*.so +} +{ + malloc-leaks-cxx-stl-string-classes-debug + Memcheck:Leak + match-leak-kinds: reachable + fun:malloc + fun:pool + fun:__static_initialization_and_destruction_0 + fun:_GLOBAL__sub_I_eh_alloc.cc + fun:call_init.part.0 + fun:call_init + fun:_dl_init + obj:*lib*/ld-2.*.so +} |
|
From: Carl L. <ce...@us...> - 2017-09-22 17:53:27
|
Ivo, Julian: Looks like our issue is the same as was seen in https://bugs.kde.org/show_bug.cgi?id=375839 The bug reports the same error and symptoms. Found the bug based on comments in guest_generic_bb_to_IR.c. /* Although we will try to disassemble up to vex_control.guest_max_insns insns into the block, the individual insn assemblers may hint to us that a disassembled instruction is verbose. In that case we will lower the limit so as to ensure that the JIT doesn't run out of space. See bug 375839 for the motivating example. */ Carl Love On Fri, 2017-09-22 at 10:20 -0700, Carl Love wrote: > On Fri, 2017-09-22 at 17:52 +0200, Ivo Raisr wrote: > > > From the comments in the code, it doesn't look like increasing the 15000 > > > is a viable option. > > > > Actually this limit is somewhat arbitrary. > > For register live ranges, type Short is used but only because invalid > > start/end range is indicated with -2. > > The rest of negative range is actually unused. > > I think this can be easily changed to UShort instead, and the limit > > raised to 62000, for example. > > > > I can send you a patch if you are interested and willing to try it. > > > > > It appears that something is just generating too > > > much stuff. I am wondering if anyone can give me some idea what is going > > > on here. It all appears to be architecture independent code. Any > > > suggestions on how to go about debugging this would be helpful. Thanks. > > > > Dump the information what the VEX JIT is doing. > > 1) Start with --trace-flags=10000000 --trace-notbelow=0 > > From the last block dumped, note the SB number. > > 2) Refine with --trace-flags=11111100 --trace-notbelow=<SB-1> > > You'll have relatively short dump with very useful information. > > > > I. > > > Ivo: > > So, with some help from Aaron, it looks like we are generating a lot of > temporaries. At one point, I see the temporary map with: > ------------------------ After pre-instr IR optimisation ------------------------ > > IRSB { > t0:F128 t1:F128 t2:F128 t3:I32 t4:I32 t5:I1 t6:I1 t7:I1 > > <cut for readability> > > t9312:I32 t9313:I32 t9314:I32 t9315:I1 t9316:I32 t9317:I32 t9318:I1 t9319:I32 > t9320:I32 t9321:I32 t9322:I1 t9323:I32 t9324:I32 t9325:I64 > > > This occurs in the middle of a block of a bunch of P9 Floating point 128 > instructions. Some of the P9 floating point 128 instructions take a > fair number of Iops to implement. I don't remember specifically for > each instruction at this point. It looks to us like there may just > be too many of these instructions in the Valgrind basic block. When the > instructions get converted to Iops it is just too big. Looking at a > partial assembly listing that Aaron gave me for the floating point test, > it looks like the assembly code is a very large sequential block of > instructions. One thought Aaron had was to see if we can tell Valgrind > to limit the size of its basic block. Not seeing a command line option > to do that. > > In VEX/priv/main_main.c > > There are the line: > > vcon->iropt_unroll_thresh = 120; > vcon->guest_max_insns = 60; > > I found if they are changed to > > vcon->iropt_unroll_thresh = 4; > vcon->guest_max_insns = 2; > > It appears to "fix" the issue. Not sure what the ramifications of > forcing these so low. Will do some more looking in the code to see what > these really do. Don't know if there is an existing mechanism to allow > contorl of this or not? Thoughts? > > Carl Love > > |
|
From: Carl L. <ce...@us...> - 2017-09-22 17:20:49
|
On Fri, 2017-09-22 at 17:52 +0200, Ivo Raisr wrote:
> > From the comments in the code, it doesn't look like increasing the 15000
> > is a viable option.
>
> Actually this limit is somewhat arbitrary.
> For register live ranges, type Short is used but only because invalid
> start/end range is indicated with -2.
> The rest of negative range is actually unused.
> I think this can be easily changed to UShort instead, and the limit
> raised to 62000, for example.
>
> I can send you a patch if you are interested and willing to try it.
>
> > It appears that something is just generating too
> > much stuff. I am wondering if anyone can give me some idea what is going
> > on here. It all appears to be architecture independent code. Any
> > suggestions on how to go about debugging this would be helpful. Thanks.
>
> Dump the information what the VEX JIT is doing.
> 1) Start with --trace-flags=10000000 --trace-notbelow=0
> From the last block dumped, note the SB number.
> 2) Refine with --trace-flags=11111100 --trace-notbelow=<SB-1>
> You'll have relatively short dump with very useful information.
>
> I.
>
Ivo:
So, with some help from Aaron, it looks like we are generating a lot of
temporaries. At one point, I see the temporary map with:
------------------------ After pre-instr IR optimisation ------------------------
IRSB {
t0:F128 t1:F128 t2:F128 t3:I32 t4:I32 t5:I1 t6:I1 t7:I1
<cut for readability>
t9312:I32 t9313:I32 t9314:I32 t9315:I1 t9316:I32 t9317:I32 t9318:I1 t9319:I32
t9320:I32 t9321:I32 t9322:I1 t9323:I32 t9324:I32 t9325:I64
This occurs in the middle of a block of a bunch of P9 Floating point 128
instructions. Some of the P9 floating point 128 instructions take a
fair number of Iops to implement. I don't remember specifically for
each instruction at this point. It looks to us like there may just
be too many of these instructions in the Valgrind basic block. When the
instructions get converted to Iops it is just too big. Looking at a
partial assembly listing that Aaron gave me for the floating point test,
it looks like the assembly code is a very large sequential block of
instructions. One thought Aaron had was to see if we can tell Valgrind
to limit the size of its basic block. Not seeing a command line option
to do that.
In VEX/priv/main_main.c
There are the line:
vcon->iropt_unroll_thresh = 120;
vcon->guest_max_insns = 60;
I found if they are changed to
vcon->iropt_unroll_thresh = 4;
vcon->guest_max_insns = 2;
It appears to "fix" the issue. Not sure what the ramifications of
forcing these so low. Will do some more looking in the code to see what
these really do. Don't know if there is an existing mechanism to allow
contorl of this or not? Thoughts?
Carl Love
|
|
From: Ivo R. <iv...@iv...> - 2017-09-22 15:53:01
|
> From the comments in the code, it doesn't look like increasing the 15000 > is a viable option. Actually this limit is somewhat arbitrary. For register live ranges, type Short is used but only because invalid start/end range is indicated with -2. The rest of negative range is actually unused. I think this can be easily changed to UShort instead, and the limit raised to 62000, for example. I can send you a patch if you are interested and willing to try it. > It appears that something is just generating too > much stuff. I am wondering if anyone can give me some idea what is going > on here. It all appears to be architecture independent code. Any > suggestions on how to go about debugging this would be helpful. Thanks. Dump the information what the VEX JIT is doing. 1) Start with --trace-flags=10000000 --trace-notbelow=0 >From the last block dumped, note the SB number. 2) Refine with --trace-flags=11111100 --trace-notbelow=<SB-1> You'll have relatively short dump with very useful information. I. |
|
From: Carl L. <ce...@us...> - 2017-09-22 15:28:45
|
Valgrind developers:
I have two users that have recently run into what appears to be the same
issue. One of the workloads is a video application, the other is a
float128 workload for the new Power 9 instructions. Both workloads fail
with the message:
Pool = TEMP, start 0x5861af28 curr 0x58adfa48 end 0x58adfa67 (size
5000000)
vex: the `impossible' happened:
VEX temporary storage exhausted.
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
I increased the N_TEMPORARY_BYTES and N_PERMANENT_BYTES #defines as
given below.
--- a/VEX/priv/main_util.c
+++ b/VEX/priv/main_util.c
@@ -55,10 +55,10 @@
#if defined(ENABLE_INNER)
/* 5 times more memory to be on the safe side: consider each
allocation is
8 bytes, and we need 16 bytes redzone before and after. */
-#define N_TEMPORARY_BYTES (5*5000000)
+#define N_TEMPORARY_BYTES (5*2000000000)
static Bool mempools_created = False;
#else
-#define N_TEMPORARY_BYTES 5000000
+#define N_TEMPORARY_BYTES 2000000000
#endif
static HChar temporary[N_TEMPORARY_BYTES]
__attribute__((aligned(REQ_ALIGN)));
@@ -70,9 +70,9 @@ static ULong temporary_bytes_allocd_TOT = 0;
#if defined(ENABLE_INNER)
/* See N_TEMPORARY_BYTES */
-#define N_PERMANENT_BYTES (5*10000)
+#define N_PERMANENT_BYTES (5*100000)
#else
-#define N_PERMANENT_BYTES 10000
+#define N_PERMANENT_BYTES 100000
Once these were increased both workloads then hit the error:
x264 [info]: profile High, level 3.1
vex: priv/host_generic_reg_alloc3.c:470 (doRegisterAllocation_v3):
Assertion `instrs_in->arr_used <= 15000' failed.
vex storage: T total 373013384 bytes allocated
vex storage: P total 192 bytes allocated
>From the comments in the code, it doesn't look like increasing the 1500
is a viable option. It appears that something is just generating too
much stuff. I am wondering if anyone can give me some idea what is going
on here. It all appears to be architecture independent code. Any
suggestions on how to go about debugging this would be helpful. Thanks.
Carl Love
|
|
From: Tom H. <to...@co...> - 2017-09-22 10:09:47
|
On 22/09/17 09:33, Ivo Raisr wrote: > 2017-09-22 7:24 GMT+02:00 John Reiser <jr...@bi...>: >> What is the purpose of the bits DF_1_INTERPOSE and DF_1_INITFIRST that are >> set in >> the DT_FLAGS_1 word of the Dynamic section of files >> $PREFIX/lib/valgrind/vgpreload_$TOOL-$ARCH-linux.so >> for which the ultimate source is: >> $ grep -e -z, Makefile* >> Makefile.all.am:PRELOAD_LDFLAGS_COMMON_LINUX = -nodefaultlibs -shared >> -Wl,-z,interpose,-z,initfirst >> Makefile.all.am:PRELOAD_LDFLAGS_COMMON_SOLARIS = -nodefaultlibs -shared >> -Wl,-z,interpose,-z,initfirst >> Makefile.tool.am:TOOL_LDFLAGS_ARM_LINUX += -Wl,-z,noexecstack >> >> Which particular symbols are those flags designed to affect? > > I can only add that Solaris followed Linux lead here. > I tried to remove the -z flags on Solaris and did not observe problems... They appear to go all the way back to commit 918c3a7b7e0 by Jeremy in 2003 so I suspect the reason for them is long since forgotten... Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Ivo R. <iv...@iv...> - 2017-09-22 08:33:23
|
2017-09-22 7:24 GMT+02:00 John Reiser <jr...@bi...>: > What is the purpose of the bits DF_1_INTERPOSE and DF_1_INITFIRST that are > set in > the DT_FLAGS_1 word of the Dynamic section of files > $PREFIX/lib/valgrind/vgpreload_$TOOL-$ARCH-linux.so > for which the ultimate source is: > $ grep -e -z, Makefile* > Makefile.all.am:PRELOAD_LDFLAGS_COMMON_LINUX = -nodefaultlibs -shared > -Wl,-z,interpose,-z,initfirst > Makefile.all.am:PRELOAD_LDFLAGS_COMMON_SOLARIS = -nodefaultlibs -shared > -Wl,-z,interpose,-z,initfirst > Makefile.tool.am:TOOL_LDFLAGS_ARM_LINUX += -Wl,-z,noexecstack > > Which particular symbols are those flags designed to affect? I can only add that Solaris followed Linux lead here. I tried to remove the -z flags on Solaris and did not observe problems... I. |
|
From: John R. <jr...@bi...> - 2017-09-22 05:24:15
|
What is the purpose of the bits DF_1_INTERPOSE and DF_1_INITFIRST that are set in
the DT_FLAGS_1 word of the Dynamic section of files
$PREFIX/lib/valgrind/vgpreload_$TOOL-$ARCH-linux.so
for which the ultimate source is:
$ grep -e -z, Makefile*
Makefile.all.am:PRELOAD_LDFLAGS_COMMON_LINUX = -nodefaultlibs -shared -Wl,-z,interpose,-z,initfirst
Makefile.all.am:PRELOAD_LDFLAGS_COMMON_SOLARIS = -nodefaultlibs -shared -Wl,-z,interpose,-z,initfirst
Makefile.tool.am:TOOL_LDFLAGS_ARM_LINUX += -Wl,-z,noexecstack
Which particular symbols are those flags designed to affect?
It seems to me that there are no symbols whose resolution changes
because the flags are present, and that it would be a bug if there were
any such symbols at all.
The symbols of valgrind and its tools never should mix with
the symbols of the target program that a valgrind tool is analyzing.
Therefore those -z flags should be omitted.
This would help usage on other platforms of the same $ARCH
(such as building valgrind for Linux and using it also for Android programs),
where other ldso do not understand INTERPOSE.
--
John
|