You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
|
From: Paul F. <pa...@so...> - 2023-04-17 20:58:28
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=54982ab5c5325a02304eccb0e16a51ad6ef9a0e3 commit 54982ab5c5325a02304eccb0e16a51ad6ef9a0e3 Author: Paul Floyd <pj...@wa...> Date: Mon Apr 17 22:57:39 2023 +0200 Forgot to add the modified file for 374596 Diff: --- VEX/priv/guest_amd64_toIR.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/VEX/priv/guest_amd64_toIR.c b/VEX/priv/guest_amd64_toIR.c index f7c3d34ce7..bb1563dc41 100644 --- a/VEX/priv/guest_amd64_toIR.c +++ b/VEX/priv/guest_amd64_toIR.c @@ -22061,9 +22061,15 @@ Long dis_ESC_0F ( /* This is a Core-i5-2300-like machine */ } else if ((archinfo->hwcaps & VEX_HWCAPS_AMD64_SSSE3) && - (archinfo->hwcaps & VEX_HWCAPS_AMD64_CX16)) { + (archinfo->hwcaps & VEX_HWCAPS_AMD64_CX16) && + (archinfo->hwcaps & VEX_HWCAPS_AMD64_RDTSCP)) { fName = "amd64g_dirtyhelper_CPUID_sse42_and_cx16"; fAddr = &amd64g_dirtyhelper_CPUID_sse42_and_cx16; + } + else if ((archinfo->hwcaps & VEX_HWCAPS_AMD64_SSSE3) && + (archinfo->hwcaps & VEX_HWCAPS_AMD64_CX16)) { + fName = "amd64g_dirtyhelper_CPUID_sse3_and_cx16"; + fAddr = &amd64g_dirtyhelper_CPUID_sse3_and_cx16; /* This is a Core-i5-670-like machine */ } else { |
|
From: Paul F. <pa...@so...> - 2023-04-17 20:07:17
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=1b3430761f6bda43b8187dbd342b34cb5c99df3f commit 1b3430761f6bda43b8187dbd342b34cb5c99df3f Author: Paul Floyd <pj...@wa...> Date: Mon Apr 17 22:05:30 2023 +0200 Bug 468401 - [PATCH] Add a style file for clang-format Patch submitted by: Petr Pavlu <pet...@da...> Diff: --- .clang-format | 17 +++++++++++++++++ .gitignore | 1 + NEWS | 1 + README_DEVELOPERS | 18 ++++++++++++++++++ 4 files changed, 37 insertions(+) diff --git a/.clang-format b/.clang-format new file mode 100644 index 0000000000..4450e737ac --- /dev/null +++ b/.clang-format @@ -0,0 +1,17 @@ +--- +Language: Cpp +BasedOnStyle: LLVM + +AlignConsecutiveAssignments: true +AlignConsecutiveDeclarations: true +AlignConsecutiveMacros: true +AllowAllParametersOfDeclarationOnNextLine: true +BinPackParameters: false +BreakBeforeBraces: Linux +ContinuationIndentWidth: 3 +IndentWidth: 3 +PointerAlignment: Left +# Mark the VG_(), ML_() and tool macros as type declarations which they are +# sufficiently close to, otherwise clang-format gets confused by them. +TypenameMacros: [VG_, ML_, CLG_, DRD_, HG_, MC_] +... diff --git a/.gitignore b/.gitignore index a88ab4dd43..6622e7c59e 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ # / /.in_place /.vs +/.clang-format /acinclude.m4 /aclocal.m4 /autom4te-*.cache diff --git a/NEWS b/NEWS index 43ff9766bd..696720e97e 100644 --- a/NEWS +++ b/NEWS @@ -152,6 +152,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 467714 fdleak_* and rlimit tests fail when parent process has more than 64 descriptors opened 467839 Gdbserver: Improve compatibility of library directory name +468401 [PATCH] Add a style file for clang-format 468556 Build failure for vgdb n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than VG_(unimplemented) diff --git a/README_DEVELOPERS b/README_DEVELOPERS index 9c04763d47..979ee13b4a 100644 --- a/README_DEVELOPERS +++ b/README_DEVELOPERS @@ -372,3 +372,21 @@ translated, and that includes the address. Then re-run with 999999 changed to the highest bb number shown. This will print the one line per block, and also will print a disassembly of the block in which the fault occurred. + + +Formatting the code with clang-format +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +clang-format is a tool to format C/C++/... code. The root directory of the +Valgrind tree contains file .clang-format which is a configuration for this tool +and specifies a style for Valgrind. This gives you an option to use +clang-format to easily format Valgrind code which you are modifying. + +The Valgrind codebase is not globally formatted with clang-format. It means +that you should not use the tool to format a complete file after making changes +in it because that would lead to creating unrelated modifications. + +The right approach is to format only updated or new code. By using an +integration with a text editor, it is possible to reformat arbitrary blocks +of code with a single keystroke. Refer to the upstream documentation which +describes integration with various editors and IDEs: +https://clang.llvm.org/docs/ClangFormat.html. |
|
From: Paul F. <pa...@so...> - 2023-04-17 19:54:29
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=41a7f59a8838a042813ac20fe1472e55e9bd5697 commit 41a7f59a8838a042813ac20fe1472e55e9bd5697 Author: Paul Floyd <pj...@wa...> Date: Mon Apr 17 21:53:23 2023 +0200 Bug 374596 - inconsistent RDTSCP support on x86_64 Diff: --- NEWS | 1 + 1 file changed, 1 insertion(+) diff --git a/NEWS b/NEWS index 6af3169d5a..43ff9766bd 100644 --- a/NEWS +++ b/NEWS @@ -124,6 +124,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 327548 false positive while destroying mutex 382034 Testcases build fixes for musl 351857 confusing error message about valid command line option +374596 inconsistent RDTSCP support on x86_64 392331 Spurious lock not held error from inside pthread_cond_timedwait 400793 pthread_rwlock_timedwrlock false positive 433873 openat2 syscall unimplemented on Linux |
|
From: Carl L. <ce...@us...> - 2023-04-17 16:22:39
|
Mark: On Sat, 2023-04-15 at 04:06 +0200, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > I have tried the tar ball on a couple of different Power 10 systems, Power 9 and Power 8. The results on the first Power 10 box with Red Hat Enterprise Linux release 9.0 (Plow) look fine: == 708 tests, 2 stderr failures, 0 stdout failures, 1 stderrB failure, 0 stdout\ B failures, 2 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The results on the second Power 10 with Fedora release 36 (Thirty Six) look a little strange: == 709 tests, 2 stderr failures, 2 stdout failures, 1 stderrB failure, 0 stdout\ B failures, 2 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/ppc64/test_isa_3_1_R1_RT (stdout) none/tests/ppc64/test_isa_3_1_R1_XT (stdout) The test_isa_3_1_R1_RT and test_isa_3_1_R1_XT tests seem to run differently then expected. The tests generate multiple lines of output when only one line was expected. For example: plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 +plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 +plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 ... (cut about 250 lines) +plfd 0_R1 =>_ -4.903986e+55 _ cb80000006100000, 0 There seem to be about 250 more copies of the output line then expected. This happens on a number of different instructions. The outputs are all identical, just more lines then expected. It appears to be a difference in how the test program runs, not in the resultgenerated by Valgrind. The output on Power 9, with Ubuntu 20.04.5 LTS == 700 tests, 4 stderr failures, 0 stdout failures, 13 stderrB failures, 0 stdoutB failures, 8 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The output for Power 8, Ubuntu 20.04.5 LTS == 696 tests, 4 stderr failures, 0 stdout failures, 13 stderrB failures, 0 stdoutB failures, 8 post failures == gdbserver_tests/hginfo (stderrB) gdbserver_tests/mcblocklistsearch (stderrB) gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcinfcallWSRU (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlgone_abrt (stderrB) gdbserver_tests/nlgone_exit (stderrB) gdbserver_tests/nlgone_return (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The Power 8 and 9 results are the same. They both have the same distro. The gdbserver tests can be a bit touchy if the versions are not a perfect match. I would expect that is the cause of the gdbserver failures. I haven't looked to see what the issue is with memcheck and massif but it is probably distro related. Not really that concerned about the results on Power 8 and 9. I will look into why the results are different on the Power 10 systems. As said, the results appear to be a test program issue not an issue with Valgrind itself. I would not hold up the release for this test failure. The RC1 release looks good to me on PowerPC. Carl |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-17 07:20:13
|
I am planning to also remove the `-I`/`--include` option from cg_annotate,
for much the same reasons that I removed user annotated files: it's an
option that made sense in the very early days of cg_annotate, but is of
little or no use today, and it's getting in the way of some other changes I
want to make.
Nick
On Tue, 4 Apr 2023 at 15:52, Nicholas Nethercote <n.n...@gm...>
wrote:
> There were no objections, and I have now removed user annotations from
> `cg_annotate`.
>
> Nick
>
> On Wed, 29 Mar 2023 at 09:03, Nicholas Nethercote <n.n...@gm...>
> wrote:
>
>> Hi,
>>
>> I recently rewrote `cg_annotate`, `cg_diff`, and `cg_merge` in Python.
>> The old versions were written in Perl, Perl, and C, respectively. The new
>> versions are much nicer and easier to modify, and I have various ideas for
>> improving `cg_annotate`. This email is about one of those ideas.
>>
>> A typical way to invoke `cg_annotate` is like this:
>>
>> > cg_annotate cachegrind.out.12345
>>
>> This implies `--auto=yes`, which requests line-by-line "auto-annotation"
>> of source files. I.e. `cg_annotate` will automatically annotate all files
>> in the profile that meet the significance threshold.
>>
>> It's also possible to do something like this:
>>
>> > cg_annotate --auto=no cachegrind.out.12345 a.c b.c
>>
>> Which instead requests "user annotation" of the files `a.c` and `b.c`.
>>
>> My thesis is that auto-annotation suffices in practice for all reasonable
>> use cases, and that user annotation is unnecessary and can be removed.
>>
>> When I first wrote `cg_annotate` in 2002, only user annotation was
>> implemented. Shortly after, I added the `--auto={yes,no}` option. Since
>> then I've never used user annotation, and I suspect nobody else has either.
>> User annotation is ok when dealing with tiny programs, but as soon as you
>> are profiling a program with more than a handful of source files it becomes
>> impractical.
>>
>> The only possible use cases I can think of for user annotation are as
>> follows.
>>
>> - If you want to see a particular file(s) annotated but you don't
>> want to see any others, then you can use user annotation in combination
>> with `--auto=no`. But it's trivial to search through the output for the
>> particular file, so this doesn't seem important.
>> - If the path to a file is somehow really messed up in the debug
>> info, it might be possible that auto-annotation would fail to find it, but
>> user annotation could find it, possibly in combination with `-I`. But this
>> seems unlikely. Some basic testing shows that gcc, clang and rustc all
>> default to using full paths in debug info. gcc supports
>> `-fdebug-prefix-map` but that seems to mostly be used for changing full
>> paths to relative paths, which will still work fine.
>>
>> Removing user annotation would (a) simplify the code and docs, and (b)
>> enable the possibility of moving the merge functionality from `cg_merge`
>> into `cg_annotate`, by allowing the user to specify multiple cachegrind.out
>> files as input.
>>
>> So: is anybody using user annotation? Does anybody see any problems with
>> this proposal?
>>
>> Thanks.
>>
>> Nick
>>
>
|
|
From: Nicholas N. <n.n...@gm...> - 2023-04-16 21:15:32
|
Hi, My plans for the release: - I have one more significant improvement to `cg_annotate` to come, which will add merge and diff capability to it, in a way that is better than the merge/diff capability provided by `cg_merge` and `cg_diff`. - I need to update the Cachegrind docs and the NEWS file for all the changes I've made. I know these will be happening late in the release cycle, but because it's all Python code it should require less testing. The likelihood of platform-specific differences in behaviour is much lower than in most other code within Valgrind. Nick On Sat, 15 Apr 2023 at 12:07, Mark Wielaard <ma...@kl...> wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc > > Please give it a try in configurations that are important for you and > report any problems you have, either on this mailing list, or > (preferably) via our bug tracker at > https://bugs.kde.org/enter_bug.cgi?product=valgrind > > There are still some patches being reviewed and a RC2 will appear end > of next week. If nothing critical emerges after that, a final release > will happen on Friday 28 April. > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Paul F. <pj...@wa...> - 2023-04-16 21:04:06
|
On 15-04-23 04:06, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc Illumos builds OK now from git HEAD. Test 3 macOS 10.13, a bit like Solaris 11.3, no pipe2 vgdb.c:91:32: warning: format specifies type 'long' but the argument has type '__darwin_suseconds_t' (aka 'int') [-Wformat] sprintf(ptr, ".%6.6ld ", dbgtv.tv_usec); ~~~~~~ ^~~~~~~~~~~~~ %6.6d /usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf' __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__) ^~~~~~~~~~~ vgdb.c:1145:8: warning: implicit declaration of function 'pipe2' is invalid in C99 [-Wimplicit-function-declaration] if (pipe2 (pipefd, O_CLOEXEC) == -1) { Builds OK from git HEAD. Test 4 Alpine (musl) Builds OK == 614 tests, 102 stderr failures, 27 stdout failures, 1 stderrB failure, 2 stdoutB failures, 4 post failures == Test 5 FreeBSD No problems same as nightly == 796 tests, 2 stderr failures, 1 stdout failure, 1 stderrB failure, 1 stdoutB failure, 0 post failures == A+ Paul |
|
From: Philippe W. <phi...@sk...> - 2023-04-16 12:36:01
|
On Sun, 2023-04-16 at 02:28 +0200, Mark Wielaard wrote: > > The problem is solved by giving an absolute path for the remote exec-file: > > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > > It doesn't need to be an absolute path, it can also be a relative path > like: set remote exec-file ./sleepers > > Note that this is similar to how valgrind normally resolves > executables. Effectively. I was confused as GDB does not use the PATH. E.G.: philippe@md:gdbserver_tests$ valgrind -q sleepers valgrind: sleepers: command not found philippe@md:gdbserver_tests$ gdb -q sleepers Loaded DUEL.py 0.9.6, high level data exploration language Reading symbols from sleepers... (gdb) start Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. So, it looks like in multi mode, I put my brain in "GDB mode". where absolute (or relative path) is not needed :). > > > > Not too sure what is going wrong/what I am doing wrong ... > > Nothing. There is something about sleepers that causes this. It also > happens for me. I'll try to debug it. But it works when you give vgdb > -d -d debug options... Humph, race condition/timing related bugs are hard to debug :(. Thanks Philippe |
|
From: Paul F. <pa...@so...> - 2023-04-16 12:29:07
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=0bc69d40a5021b158804fb4f39592596333f7013 commit 0bc69d40a5021b158804fb4f39592596333f7013 Author: Paul Floyd <pj...@wa...> Date: Sun Apr 16 14:27:04 2023 +0200 illunmos: fix configure scf_handle_bind check Migration to GCC 10 changes to 64bit load, see https://github.com/omniosorg/omnios-extra/blob/master/build/valgrind/patches/libscf.patch Diff: --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a886d0deaa..a439ec85d9 100755 --- a/configure.ac +++ b/configure.ac @@ -4513,11 +4513,11 @@ if test "X$VGCONF_ARCH_PRI" = "Xamd64"; then else libscf=/usr/lib/libscf.so.1 fi -if ! $DIS_PATH -F scf_handle_bind $libscf | grep -q 0x526570; then +if ! $DIS_PATH -F scf_handle_bind $libscf | grep -q -E '0x(4d01)?526570'; then AC_MSG_WARN([Function `scf_handle_bind' does not contain repository cache protocol version.]) AC_MSG_ERROR([Cannot determine version of the repository cache protocol.]) fi -hex=$( $DIS_PATH -F scf_handle_bind $libscf | sed -n 's/.*0x526570\(..\).*/\1/p' ) +hex=$( $DIS_PATH -F scf_handle_bind $libscf | perl -pe '($_) = /0x(?:4d01)?526570(\d{2}),/' ) if test -z "$hex"; then AC_MSG_WARN([Version of the repository cache protocol is empty?!]) AC_MSG_ERROR([Cannot determine version of the repository cache protocol.]) |
|
From: Paul F. <pj...@wa...> - 2023-04-16 11:28:40
|
On 15-04-23 04:06, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc > > Please give it a try in configurations that are important for you and > report any problems you have, either on this mailing list, or > (preferably) via our bug tracker at > https://bugs.kde.org/enter_bug.cgi?product=valgrind Test 2, Illumos (OpenIndiana 22.10 with latest pkg update) Configure failure related to this check if ! $DIS_PATH -F scf_handle_bind $libscf | grep -q 0x526570; then The constant used now seems to be 0x4d0152657015 Just dropping the 0x seems to work. A+ Paul |
|
From: Mark W. <ma...@so...> - 2023-04-16 11:19:21
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=932332e660a458e51068937130d557fb4acc6630 commit 932332e660a458e51068937130d557fb4acc6630 Author: Mark Wielaard <ma...@kl...> Date: Sun Apr 16 13:15:03 2023 +0200 Use pipe in vgdb if system doesn't have pipe2 Add a configure check for pipe2. If it isn't available use pipe and fcntl F_SETFD FD_CLOEXEC in vgdb.c. https://bugs.kde.org/show_bug.cgi?id=468556 Diff: --- NEWS | 1 + configure.ac | 1 + coregrind/vgdb.c | 17 +++++++++++++++++ 3 files changed, 19 insertions(+) diff --git a/NEWS b/NEWS index a8ab817e17..6af3169d5a 100644 --- a/NEWS +++ b/NEWS @@ -151,6 +151,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 467714 fdleak_* and rlimit tests fail when parent process has more than 64 descriptors opened 467839 Gdbserver: Improve compatibility of library directory name +468556 Build failure for vgdb n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than VG_(unimplemented) To see details of a given bug, visit diff --git a/configure.ac b/configure.ac index 66437a8000..a886d0deaa 100755 --- a/configure.ac +++ b/configure.ac @@ -4820,6 +4820,7 @@ AC_CHECK_FUNCS([ \ memset \ mkdir \ mremap \ + pipe2 \ ppoll \ preadv \ preadv2 \ diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index c4a7042984..7ed9a8b2e9 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -1142,11 +1142,28 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir, // We will use a pipe to track what the child does, // so we can report failure. int pipefd[2]; +#ifdef HAVE_PIPE2 if (pipe2 (pipefd, O_CLOEXEC) == -1) { err = errno; perror ("pipe2 failed"); return err; } +#else + if (pipe (pipefd) == -1) { + err = errno; + perror ("pipe failed"); + return err; + } else { + if (fcntl (pipefd[0], F_SETFD, FD_CLOEXEC) == -1 + || fcntl (pipefd[1], F_SETFD, FD_CLOEXEC) == -1) { + err = errno; + perror ("fcntl failed"); + close (pipefd[0]); + close (pipefd[1]); + return err; + } + } +#endif pid_t p = fork (); if (p < 0) { |
|
From: Paul F. <pj...@wa...> - 2023-04-16 07:44:33
|
On 04/15/23 04:06 AM, Mark Wielaard wrote: > An RC1 tarball for 3.21.0 is now available at > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 > (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) > (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) > https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc > First test, Solaris 11.3/ Build fails because pipe2 is not available. Also logged as https://bugs.kde.org/show_bug.cgi?id=468556 gcc -std=gnu11 -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -Wl,-M,/usr/lib/ld/map.noexstk -o valgrind valgrind-launcher-linux.o valgrind-m_debuglog.o gcc -std=gnu11 -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op -Wold-style-declaration -finline-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -o vgdb vgdb-vgdb.o vgdb-vgdb-invoker-solaris.o -lsocket Undefined first referenced symbol in file pipe2 vgdb-vgdb.o ld: fatal: symbol referencing errors collect2: error: ld returned 1 exit status gmake[3]: *** [vgdb] Error 1 gmake[3]: *** Waiting for unfinished jobs.... mv -f m_replacemalloc/.deps/libreplacemalloc_toolpreload_x86_solaris_a-vg_replace_malloc.Tpo m_replacemalloc/.deps/libreplacemalloc_toolpreload_x86_solaris_a-vg_replace_malloc.Po mv -f m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-generic.Tpo m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-generic.Po mv -f m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-solaris.Tpo m_syswrap/.deps/libcoregrind_x86_solaris_a-syswrap-solaris.Po gmake[3]: Leaving directory `/export/home/paulf/test321/valgrind-3.21.0.RC1/coregrind' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/export/home/paulf/test321/valgrind-3.21.0.RC1/coregrind' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/export/home/paulf/test321/valgrind-3.21.0.RC1' gmake: *** [all] Error 2 A+ Paul |
|
From: Mark W. <ma...@kl...> - 2023-04-16 00:28:21
|
Hi Philippe, Thanks for testing things out. On Sat, Apr 15, 2023 at 07:58:16PM +0200, Philippe Waroquiers wrote: > I did some tests: > > philippe@md:gdbserver_tests$ gdb sleepers > GNU gdb (GDB) 14.0.50.20230402-git > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Loaded DUEL.py 0.9.6, high level data exploration language > Reading symbols from sleepers... > (gdb) set remote exec-file sleepers > (gdb) set sysroot / > (gdb) target extended-remote | vgdb --multi > Remote debugging using | vgdb --multi > (gdb) start > Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. > Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > valgrind: sleepers: command not found > syscall failed: No such file or directory > error opening /tmp/vgdb-pipe-shared-mem-vgdb-52790-by-philippe-on-md shared memory file > Remote communication error. Target disconnected.: Connection reset by peer. > (gdb) > > > > The problem is solved by giving an absolute path for the remote exec-file: > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers It doesn't need to be an absolute path, it can also be a relative path like: set remote exec-file ./sleepers Note that this is similar to how valgrind normally resolves executables. $ valgrind sleepers valgrind: sleepers: command not found $ valgrind ./sleepers ==210626== Memcheck, a memory error detector ==210626== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==210626== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==210626== Command: ./sleepers ==210626== loops/sleep_ms/burn/threads_spec/affinity: 15 1000 0 BSBSBSBS 0 Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Brussels finished to sleep and/or burn London finished to sleep and/or burn main finished to sleep and/or burn Petaouchnok finished to sleep and/or burn [...] > So, it looks like gdb knows the absolute path of the program to launch, but does not pass > it to valgrind. It might be possible to have the full path given to vgdb ? Yes that would be nice. Tom Tromey suggested we create a python plugin to do some of the things we are currently requiring the user to set by hand. Paul made a gdb alias that does some of it. I hope we will add a new target valgrind to gdb itself that will do that and that does the stdin/stdout redirecting (that is a current issue with target extended-remote | ... it will "eat" the stdin/out of the child process). > The vgdb --help output is missing the --valgrind and the --vargs in the OPTIONS summary: > OPTIONS are [--pid=<number>] [--vgdb-prefix=<prefix>] > [--wait=<number>] [--max-invoke-ms=<number>] > [--port=<portnr> > [--cmd-time-out=<number>] [-l] [-T] [-D] [-d] > [--multi] > > The vgdb --help is missing \n after the --vargs description: > --vargs everything that follows is an argument for valgrind. -l arg tells to show the list of running Valgrind gdbserver and then exit. Oops. Fixed. > For > --valgrind, pass the path to valgrind to use. If not specified, the system valgrind will be launched. > Wouldn't it better (if possible) to by default launch the valgrind found at the same place as where vgdb is found ? Yes that would be nice, I'll look into it. But I think that normally if vgdb is on the PATH then so will valgrind. > Finally, once giving an absolute remote exec-file and an absolute path to the valgrind to launch, > I cannot have it working: > gdb sleepers > GNU gdb (GDB) 14.0.50.20230402-git > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-pc-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <https://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Loaded DUEL.py 0.9.6, high level data exploration language > Reading symbols from sleepers... > (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > (gdb) set sysroot / > (gdb) target extended-remote | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind > Remote debugging using | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind > (gdb) start > Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. > Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > ==100738== Memcheck, a memory error detector > ==100738== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. > ==100738== Using Valgrind-3.21.0.RC1 and LibVEX; rerun with -h for copyright info > ==100738== Command: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers > ==100738== > relaying data between gdb and process 100738 > syscall failed: Resource temporarily unavailable > error reading static buf readchar > syscall failed: Resource temporarily unavailable > readchar > no ack mode: unexpected buflen -1, buf > Unknown remote qXfer reply: 1 > (gdb) quit > > Not too sure what is going wrong/what I am doing wrong ... Nothing. There is something about sleepers that causes this. It also happens for me. I'll try to debug it. But it works when you give vgdb -d -d debug options... Cheers, Mark |
|
From: Mark W. <ma...@so...> - 2023-04-16 00:01:06
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=03d9229f0bdb28cf35e3bfc98010952594b091cd commit 03d9229f0bdb28cf35e3bfc98010952594b091cd Author: Mark Wielaard <ma...@kl...> Date: Sun Apr 16 01:55:48 2023 +0200 Fixup vgdb --help message The --valgrind and the --vargs were missingin the OPTIONS summary. A \n was missing after the --vargs description. Diff: --- coregrind/vgdb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index 1cc37a3566..c4a7042984 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -1899,7 +1899,7 @@ void usage(void) " [--wait=<number>] [--max-invoke-ms=<number>]\n" " [--port=<portnr>\n" " [--cmd-time-out=<number>] [-l] [-T] [-D] [-d]\n" -" [--multi]\n" +" [--multi] [--valgrind=<valgrind-exe>] [--vargs ...]\n" " \n" " --pid arg must be given if multiple Valgrind gdbservers are found.\n" " --vgdb-prefix arg must be given to both Valgrind and vgdb utility\n" @@ -1915,7 +1915,7 @@ void usage(void) " gdbserver has not processed a command after number seconds\n" " --multi start in extended-remote mode, wait for gdb to tell us what to run\n" " --valgrind, pass the path to valgrind to use. If not specified, the system valgrind will be launched.\n" -" --vargs everything that follows is an argument for valgrind." +" --vargs everything that follows is an argument for valgrind.\n" " -l arg tells to show the list of running Valgrind gdbserver and then exit.\n" " -T arg tells to add timestamps to vgdb information messages.\n" " -D arg tells to show shared mem status and then exit.\n" |
|
From: Philippe W. <phi...@sk...> - 2023-04-15 20:27:53
|
Some additional comments below ... Thanks Philippe On Thu, 2023-04-13 at 22:09 +0000, Mark Wielaard wrote: > https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=0432ce486d61f84f6fcbeab0d812bb1f61c57561 > > commit 0432ce486d61f84f6fcbeab0d812bb1f61c57561 > Author: Alexandra Petlanova Hajkova <aha...@re...> > Date: Thu Mar 3 04:46:03 2022 -0500 > > vgdb: implement the extended-remote protocol > > > > Executing vgdb --multi makes vgdb talk the gdb extended-remote > protocol. This means that the gdb run command is supported and > vgdb will start up the program under valgrind. Which means you > don't need to run gdb and valgrind from different terminals. > Also vgdb keeps being connected to gdb after valgrind exits. So > you can easily rerun the program with the same breakpoints in > place. > > > > vgdb now implements a minimal gdbserver that just recognizes > a few extended-remote protocol packets. Once it starts up valgrind > it sets up noack and qsupported then it will forward packets > between gdb and valgrind gdbserver. After valgrind shutsdown it > resumes handling gdb packets itself. > > > > https://bugs.kde.org/show_bug.cgi?id=434057 > > > > Co-authored-by: Mark Wielaard <ma...@kl...> valgrind --help does not describe the 'multi' related option, but --help-debug describes it. That was a little bit surprising to me. As this is not a real user option, it however does not fully fit in the section: uncommon user options for all Valgrind tools: > > diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c > index 9a9b90e585..1cc37a3566 100644 > --- a/coregrind/vgdb.c > +++ b/coregrind/vgdb.c > > /* vgdb has two usages: Maybe this should describe here 3 usages ? > @@ -169,7 +175,17 @@ void map_vgdbshared(char* shared_mem) > { > struct stat fdstat; > void **s; > - shared_mem_fd = open(shared_mem, O_RDWR); > + int tries = 50; > + int err; > + > + /* valgrind might still be starting up, give it 5 seconds. */ Maybe the --wait arg (if provided) could override this hard-coded value ? > +/* Returns an allocated hex-decoded string from the buf starting at offset > + off. Will update off to where the buf has been decoded. Stops decoding > + at end of buf (zero) or when seeing the delim char. */ The comment seems not aligned with the below function (e.g. there is no off arg). > +static > +char *decode_hexstring (const char *buf, size_t prefixlen, size_t len) > +{ > + int buflen; > + char *buf_print; > + > + if (len) > + buflen = len; > + else > + buflen = strlen(buf) - prefixlen; > + > + buf_print = vmalloc (buflen/2 + 1); > + > + for (int i = 0; i < buflen; i = i + 2) { > + buf_print[i/2] = ((fromhex(buf[i+prefixlen]) << 4) > + + fromhex(buf[i+prefixlen+1])); > + } > + buf_print[buflen/2] = '\0'; > + DEBUG(1, "decode_hexstring: %s\n", buf_print); > + return buf_print; > +} > + > > > > + > +/* Creates a packet from a string message, called needs to free. */ caller needs to free ? > +static char * > +create_packet(const char *msg) > In some functions from here onwards, there are a bunch of indentation with 4 spaces while the rest of vgdb.c is 3. > + > +static int read_one_char (char *c) > +{ > + int i; > + do > + i = read (from_gdb, c, 1); > + while (i == -1 && errno == EINTR); > + > + return i; > +} > + > > + > +// Throws away the packet name and decodes the hex string, which is placed in What is the packet name ? > +// decoded_string (the caller owns this and is responsible for freeing it). > +static int split_hexdecode(const char *buf, const char *string, > + const char *delim, char **decoded_string) > +{ > + const char *next_str = next_delim_string(buf, *delim); > + if (next_str) { > + *decoded_string = decode_hexstring (next_str, 0, 0); > + DEBUG(1, "split_hexdecode decoded %s\n", *decoded_string); > + return 1; > + } else { > + TSFPRINTF(stderr, "%s decoding error: finding the hex string in %s failed!\n", string, buf); > + return 0; > + } > +} > + > +static int count_delims(char delim, char *buf) This should return a size_t > +{ > + size_t count = 0; > + char *ptr = buf; > + > + while (*ptr) > + count += *ptr++ == delim; > + return count; > +} > + > > > +/* Do multi stuff. */ > +static > +void do_multi_mode(void) > +{ > + char *buf = vmalloc(PBUFSIZ+1); > + char *q_buf = vmalloc(PBUFSIZ+1); //save the qSupported packet sent by gdb > + //to send it to the valgrind gdbserver later > + q_buf[0] = '\0'; > + int noackmode = 0, pkt_size = 0, bad_unknown_packets = 0; > + char *string = NULL; > + char *working_dir = NULL; > + DEBUG(1, "doing multi stuff...\n"); > + while (1){ > + /* We get zero if the pipe was closed (EOF), or -1 on error reading from > + the pipe to gdb. */ > + pkt_size = receive_packet(buf, noackmode); > + if (pkt_size <= 0) { > + DEBUG(1, "receive_packet: %d\n", pkt_size); > + break; > + } > + > + DEBUG(1, "packet recieved: '%s'\n", buf); typo: received > + > +#define QSUPPORTED "qSupported:" > +#define STARTNOACKMODE "QStartNoAckMode" > +#define QRCMD "qRcmd" // This is the monitor command in gdb > +#define VRUN "vRun" > +#define XFER "qXfer" > +#define QATTACHED "qAttached" > +#define QENVIRONMENTHEXENCODED "QEnvironmentHexEncoded" > +#define QENVIRONMENTRESET "QEnvironmentReset" > +#define QENVIRONMENTUNSET "QEnvironmentUnset" > +#define QSETWORKINGDIR "QSetWorkingDir" > +#define QTSTATUS "qTStatus" > + > + if (strncmp(QSUPPORTED, buf, strlen(QSUPPORTED)) == 0) { > + DEBUG(1, "CASE %s\n", QSUPPORTED); > + // And here is our reply. > + // XXX error handling? We don't check the arguments. > + char *reply; > + strcpy(q_buf, buf); > + // Keep this in sync with coregrind/m_gdbserver/server.c Worth adding a note in server.c to also point at this place ? > + asprintf (&reply, > + "PacketSize=%x;" > + "QStartNoAckMode+;" > + "QPassSignals+;" > + "QCatchSyscalls+;" > + /* Just report support always. */ > + "qXfer:auxv:read+;" > + /* We'll force --vgdb-shadow-registers=yes */ > + "qXfer:features:read+;" > + "qXfer:exec-file:read+;" > + "qXfer:siginfo:read+;" > + /* Some extra's vgdb support before valgrind starts up. */ > + "QEnvironmentHexEncoded+;" > + "QEnvironmentReset+;" > + "QEnvironmentUnset+;" > + "QSetWorkingDir+", (UInt)PBUFSIZ - 1); > + send_packet(reply, noackmode); > + free (reply); > + } > + else if (strncmp(STARTNOACKMODE, buf, strlen(STARTNOACKMODE)) == 0) { > + // We have to ack this one > + send_packet("OK", 0); > + noackmode = 1; > + } > + else if (buf[0] == '!') { > + send_packet("OK", noackmode); > + } > + else if (buf[0] == '?') { > + send_packet("W00", noackmode); > + } > + else if (strncmp("H", buf, strlen("H")) == 0) { > + // Set thread packet, but we are not running yet. > + send_packet("E01", noackmode); > + } > + else if (strncmp("vMustReplyEmpty", buf, strlen("vMustReplyEmpty")) == 0) { > + send_packet ("", noackmode); > + } > + else if (strncmp(QRCMD, buf, strlen(QRCMD)) == 0) { > + send_packet ("No running target, monitor commands not available yet.", noackmode); > + > + char *decoded_string = decode_hexstring (buf, strlen (QRCMD) + 1, 0); > + DEBUG(1, "qRcmd decoded: %s\n", decoded_string); > + free (decoded_string); > + } > + else if (strncmp(VRUN, buf, strlen(VRUN)) == 0) { > + // vRun;filename[;argument]* > + // vRun, filename and arguments are split on ';', > + // no ';' at the end. > + // If there are no arguments count is one (just the filename). > + // Otherwise it is the number of arguments plus one (the filename). > + // The filename must be there and starts after the first ';'. > + // TODO: Handle vRun;[;argument]* > + // https://www.sourceware.org/gdb/onlinedocs/gdb/Packets.html#Packets > + // If filename is an empty string, the stub may use a default program > + // (e.g. the last program run). > + size_t count = count_delims(';', buf); > + size_t *len = vmalloc(count * sizeof(count)); > + const char *delim = ";"; > + const char *next_str = next_delim_string(buf, *delim); > + char **decoded_string = vmalloc(count * sizeof (char *)); > + > + // Count the lenghts of each substring, init to -1 to compensate for typo: lenghts > + // each substring starting with a delim char. > + for (int i = 0; i < count; i++) > + len[i] = -1; > + count_len(';', buf, len); > + if (next_str) { > + DEBUG(1, "vRun: next_str %s\n", next_str); > + for (int i = 0; i < count; i++) { > + /* Handle the case when the arguments > + * was specified to gdb's run command > + * but no remote exec-file was set, > + * so the first vRun argument is missing. > + * For example vRun;;6c. */ > + if (*next_str == *delim) { > + next_str++; > + /* empty string that can be freed. */ > + decoded_string[i] = strdup(""); > + } > + else { > + decoded_string[i] = decode_hexstring (next_str, 0, len[i]); > + if (i < count - 1) > + next_str = next_delim_string(next_str, *delim); > + } > + DEBUG(1, "vRun decoded: %s, next_str %s, len[%d] %d\n", decoded_string[i], next_str, i, len[i]); Line too long. > + } > + > + /* If we didn't get any arguments or the filename is an empty > + string, valgrind won't know which program to run. */ > + DEBUG (1, "count: %d, len[0]: %d\n", count, len[0]); > + if (! count || len[0] == 0) { > + free(len); > + for (int i = 0; i < count; i++) > + free (decoded_string[i]); > + free (decoded_string); > + send_packet ("E01", noackmode); > + continue; > + } > + > + /* We have collected the decoded strings so we can use them to > + launch valgrind with the correct arguments... We then use the > + valgrind pid to start relaying packets. */ > + pid_t valgrind_pid = -1; > + int res = fork_and_exec_valgrind (count, > + decoded_string, > + working_dir, > + &valgrind_pid); > + > + if (res == 0) { > + // Lets report we Stopped with SIGTRAP (05). > + send_packet ("S05", noackmode); > + prepare_fifos_and_shared_mem(valgrind_pid); > + DEBUG(1, "from_gdb_to_pid %s, to_gdb_from_pid %s\n", from_gdb_to_pid, to_gdb_from_pid); line too long > + // gdb_rely is an endless loop till valgrind quits. typo: gdb_rely > + shutting_down = False; > + > + gdb_relay (valgrind_pid, 1, q_buf); > + cleanup_fifos_and_shared_mem(); > + DEBUG(1, "valgrind relay done\n"); > + int status; > + pid_t p = waitpid (valgrind_pid, &status, 0); > + DEBUG(2, "waitpid: %d\n", (int) p); > + if (p == -1) > + DEBUG(1, "waitpid error %s\n", strerror (errno)); > + else { > + if (WIFEXITED(status)) > + DEBUG(1, "valgrind exited with %d\n", > + WEXITSTATUS(status)); > + else if (WIFSIGNALED(status)) > + DEBUG(1, "valgrind kill by signal %d\n", > + WTERMSIG(status)); > + else > + DEBUG(1, "valgind unexpectedly stopped or continued"); typo: valgind > + } > + } else { > + send_packet ("E01", noackmode); > + DEBUG(1, "OOPS! couldn't launch valgrind %s\n", > + strerror (res)); > + } > + > + free(len); > + for (int i = 0; i < count; i++) > + free (decoded_string[i]); > + free (decoded_string); > + } else { > + free(len); > + send_packet ("E01", noackmode); missing indentation > + DEBUG(1, "vRun decoding error: no next_string!\n"); > + continue; > + } > + } else if (strncmp(QATTACHED, buf, strlen(QATTACHED)) == 0) { > + send_packet ("1", noackmode); > + DEBUG(1, "qAttached sent: '1'\n"); > + const char *next_str = next_delim_string(buf, ':'); > + if (next_str) { > + char *decoded_string = decode_hexstring (next_str, 0, 0); > + DEBUG(1, "qAttached decoded: %s, next_str %s\n", decoded_string, next_str); > + free (decoded_string); > + } else { > + DEBUG(1, "qAttached decoding error: strdup of %s failed!\n", buf); > + continue; > + } > + } /* Reset the state of environment variables in the remote target before starting > + the inferior. In this context, reset means unsetting all environment variables > + that were previously set by the user (i.e., were not initially present in the environment). */ line too long Below we have indentation with 5 chars at many places. > + else if (strncmp(QENVIRONMENTRESET, buf, > + strlen(QENVIRONMENTRESET)) == 0) { > + send_packet ("OK", noackmode); > + // TODO clear all environment strings. We're not using > + // environment strings now. But we should. > + } else if (strncmp(QENVIRONMENTHEXENCODED, buf, > + strlen(QENVIRONMENTHEXENCODED)) == 0) { > + send_packet ("OK", noackmode); > + if (!split_hexdecode(buf, QENVIRONMENTHEXENCODED, ":", &string)) > + break; > + // TODO Collect all environment strings and add them to environ > + // before launcing valgrind. typo: launcing > + free (string); > + string = NULL; > + } else if (strncmp(QENVIRONMENTUNSET, buf, > + strlen(QENVIRONMENTUNSET)) == 0) { > + send_packet ("OK", noackmode); > + if (!split_hexdecode(buf, QENVIRONMENTUNSET, ":", &string)) > + break; > + // TODO Remove this environment string from the collection. > + free (string); > + string = NULL; > + } else if (strncmp(QSETWORKINGDIR, buf, > + strlen(QSETWORKINGDIR)) == 0) { > + // Silly, but we can only reply OK, even if the working directory is > + // bad. Errors will be reported when we try to execute the actual > + // process. > + send_packet ("OK", noackmode); > + // Free any previously set working_dir > + free (working_dir); > + working_dir = NULL; > + if (!split_hexdecode(buf, QSETWORKINGDIR, ":", &working_dir)) { > + continue; // We cannot report the error to gdb... > + } > + DEBUG(1, "set working dir to: %s\n", working_dir); > + } else if (strncmp(XFER, buf, strlen(XFER)) == 0) { > + char *buf_dup = strdup(buf); > + DEBUG(1, "strdup: buf_dup %s\n", buf_dup); > + if (buf_dup) { > + const char *delim = ":"; > + size_t count = count_delims(delim[0], buf); > + if (count < 4) { > + strsep(&buf_dup, delim); > + strsep(&buf_dup, delim); > + strsep(&buf_dup, delim); > + char *decoded_string = decode_hexstring (buf_dup, 0, 0); > + DEBUG(1, "qXfer decoded: %s, buf_dup %s\n", decoded_string, buf_dup); > + free (decoded_string); > + } > + free (buf_dup); > + } else { > + DEBUG(1, "qXfer decoding error: strdup of %s failed!\n", buf); > + free (buf_dup); > + continue; > + } > + // Whether we could decode it or not, we cannot handle it now. We > + // need valgrind gdbserver to properly reply. So error out here. > + send_packet ("E00", noackmode); > + } else if (strncmp(QTSTATUS, buf, strlen(QTSTATUS)) == 0) { > + // We don't support trace experiments > + DEBUG(1, "Got QTSTATUS\n"); > + send_packet ("", noackmode); > + } else if (strcmp("qfThreadInfo", buf) == 0) { > + DEBUG(1, "Got qfThreadInfo\n"); > + /* There are no threads yet, reply 'l' end of list. */ > + send_packet ("l", noackmode); > + } else if (buf[0] != '\0') { > + // We didn't understand. > + DEBUG(1, "Unknown packet received: '%s'\n", buf); > + bad_unknown_packets++; > + if (bad_unknown_packets > 10) { > + DEBUG(1, "Too many bad/unknown packets received\n"); > + break; > + } > + send_packet ("", noackmode); > + } > + } > + DEBUG(1, "done doing multi stuff...\n"); > + free(working_dir); > + free(buf); > + free(q_buf); > + > + shutting_down = True; > + close (to_gdb); > + close (from_gdb); > +} > + > +/* Relay data between gdb and Valgrind gdbserver, till EOF or an error is > + encountered. q_buf is the qSupported packet received from gdb. */ > +static > +void gdb_relay(int pid, int send_noack_mode, char *q_buf) > { > int from_pid = -1; /* fd to read from pid */ > int to_pid = -1; /* fd to write to pid */ > @@ -863,6 +1569,16 @@ void gdb_relay(int pid) ... > @@ -1379,6 +2135,7 @@ void parse_options(int argc, char** argv, > TSFPRINTF(stderr, "%s is not a correct path. %s, exiting.\n", path, strerror (errno)); Line too long. ... > // argc - i is the number of left over arguments > // allocate enough space, but all args in it. Not clear what is meant by 'but all args in it.' > @@ -1275,6 +1298,19 @@ Therefore, it has two usage modes: > </para> > </listitem> > > + <listitem id="manual-core-adv.vgdb-multi" xreflabel="vgdb multi"> > + <para>In the <option>--multi</option> mode, Vgdb uses the extended Elsewhere in the doc, we use vgdb, not Vgdb. > + remote protocol to communicate with Gdb. This allows you to view And we use GDB, not Gdb. > + output from both valgrind and GDB in the GDB session. This is > + accomplished via the "target extended-remote | vgdb --multi". In > + this mode you no longer need to start valgrind yourself. vgdb will > + start up valgrind when gdb tells it to run a new program. For this > + usage, the vgdb OPTIONS(s) can also include <option>--valgrind</option> > + and <option>--vargs</option> to describe how valgrind should be > + started. > + </para> > + </listitem> |
|
From: Paul F. <pj...@wa...> - 2023-04-15 19:43:30
|
On 15-04-23 19:58, Philippe Waroquiers via Valgrind-developers wrote:
> Not too sure what is going wrong/what I am doing wrong ...
> (tested with 53834800424510b177c59d097c3a51a66bbaf659)
At first I tried running from the build dir, but that was complicated so
I switched to using it from my home dir install.
I also use the following functions in my .gdbinit file (hopefully this
will become easier eventually). It works, but doesn't allow you to
specify your own --vargs
define set-program-name
set logging file tmp.gdb
set logging overwrite on
set logging redirect on
set logging enabled on
python print(f"set $programname =
\"{gdb.current_progspace().filename}\"")
set logging enabled off
set logging redirect off
set logging overwrite off
source tmp.gdb
end
define start_vg
set-program-name
eval "set remote exec-file %s", $programname
show remote exec-file
set sysroot /
target extended-remote | vgdb --multi --vargs -q
start
end
A+
Paul
|
|
From: Philippe W. <phi...@sk...> - 2023-04-15 17:58:27
|
On Thu, 2023-04-13 at 22:09 +0000, Mark Wielaard wrote: > +* The vgdb utility now supports extended-remote protocol when > + invoked with --multi. In this mode the GDB run command is > + supported. Which means you don't need to run gdb and valgrind > + from different terminals. So for example to start you program > + in gdb and run it under valgrind you can do: > + $ gdb prog > + (gdb) set remote exec-file prog > + (gdb) set sysroot / > + (gdb) target extended-remote | vgdb --multi > + (gdb) start Thanks to Mark and Alexandra for this work (and sorry for the lack of earlier feedback about this). I did some tests: philippe@md:gdbserver_tests$ gdb sleepers GNU gdb (GDB) 14.0.50.20230402-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Loaded DUEL.py 0.9.6, high level data exploration language Reading symbols from sleepers... (gdb) set remote exec-file sleepers (gdb) set sysroot / (gdb) target extended-remote | vgdb --multi Remote debugging using | vgdb --multi (gdb) start Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers valgrind: sleepers: command not found syscall failed: No such file or directory error opening /tmp/vgdb-pipe-shared-mem-vgdb-52790-by-philippe-on-md shared memory file Remote communication error. Target disconnected.: Connection reset by peer. (gdb) The problem is solved by giving an absolute path for the remote exec-file: (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers So, it looks like gdb knows the absolute path of the program to launch, but does not pass it to valgrind. It might be possible to have the full path given to vgdb ? The vgdb --help output is missing the --valgrind and the --vargs in the OPTIONS summary: OPTIONS are [--pid=<number>] [--vgdb-prefix=<prefix>] [--wait=<number>] [--max-invoke-ms=<number>] [--port=<portnr> [--cmd-time-out=<number>] [-l] [-T] [-D] [-d] [--multi] The vgdb --help is missing \n after the --vargs description: --vargs everything that follows is an argument for valgrind. -l arg tells to show the list of running Valgrind gdbserver and then exit. For --valgrind, pass the path to valgrind to use. If not specified, the system valgrind will be launched. Wouldn't it better (if possible) to by default launch the valgrind found at the same place as where vgdb is found ? Finally, once giving an absolute remote exec-file and an absolute path to the valgrind to launch, I cannot have it working: gdb sleepers GNU gdb (GDB) 14.0.50.20230402-git Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Loaded DUEL.py 0.9.6, high level data exploration language Reading symbols from sleepers... (gdb) set remote exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers (gdb) set sysroot / (gdb) target extended-remote | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind Remote debugging using | vgdb --multi --valgrind=/home/philippe/valgrind/git/trunk_untouched/Inst/bin/valgrind (gdb) start Temporary breakpoint 1 at 0x16fc: file sleepers.c, line 138. Starting program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers ==100738== Memcheck, a memory error detector ==100738== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==100738== Using Valgrind-3.21.0.RC1 and LibVEX; rerun with -h for copyright info ==100738== Command: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers ==100738== relaying data between gdb and process 100738 syscall failed: Resource temporarily unavailable error reading static buf readchar syscall failed: Resource temporarily unavailable readchar no ack mode: unexpected buflen -1, buf Unknown remote qXfer reply: 1 (gdb) quit Not too sure what is going wrong/what I am doing wrong ... (tested with 53834800424510b177c59d097c3a51a66bbaf659) Thanks Philippe |
|
From: Paul F. <pj...@wa...> - 2023-04-15 11:29:04
|
Hi Here's a list of the items that, time permitting, I'd like to get into 3.21. Plus any recently-released FreeBSD 13.2 fixes. inconsistent RDTSCP support on x86_64 https://bugs.kde.org/show_bug.cgi?id=374596 I was recently contacted by the patch author for this one. It's a bit tricky to test as it requires ancient hardware or some sort of virtualization. That or a good knowledge of all possible hwcaps combinations. Likely false positive "uninitialised value(s)" for __wmemchr_avx2 and __wmemcmp_avx2_movbe https://bugs.kde.org/show_bug.cgi?id=397083 Looks fairly straightforward, I just need to find a machine less old than mine to test it on. Enhancement: add a client request to DHAT to mark memory to be histogrammed https://bugs.kde.org/show_bug.cgi?id=464103 Again fairly simple and straightforward. Add mismatched detection to C++ 17 aligned new/delete https://bugs.kde.org/show_bug.cgi?id=433859 Add validation to C++17 aligned new/delete alignment size https://bugs.kde.org/show_bug.cgi?id=433857 Add mismatched detection to C++ 14 sized delete https://bugs.kde.org/show_bug.cgi?id=467441 aligned_alloc problems, part 2 https://bugs.kde.org/show_bug.cgi?id=466105 There's a lot of stuff there (patch in the first bugzi item). All the C++ stuff is nice to have (and mostly also covered by ASan) but I don't think that that kind of error happens frequently in the wild. memalign and aligned alloc are more likely to be useful for detecting implementation defined behaviour. A+ Paul |
|
From: Mark W. <ma...@kl...> - 2023-04-15 02:07:05
|
An RC1 tarball for 3.21.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2 (md5sum = a3c7eeff47262cecdf5f1d68b38710b7) (sha1sum = 46fc5898415001e045abc1b4e2909a41144ed9c4) https://sourceware.org/pub/valgrind/valgrind-3.21.0.RC1.tar.bz2.asc Please give it a try in configurations that are important for you and report any problems you have, either on this mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind There are still some patches being reviewed and a RC2 will appear end of next week. If nothing critical emerges after that, a final release will happen on Friday 28 April. |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-15 01:50:36
|
On Sat, 15 Apr 2023 at 11:00, Mark Wielaard <ma...@kl...> wrote: > > When you add the doc changes could you also add a NEWS entry? > Yes, it's on my todo list. > Note that under --branch-sim=no|yes [no] cachegrind/docs/cg-manual.xml > says: > > <para>Enables or disables collection of branch instruction and > misprediction counts. By default this is disabled as it > slows Cachegrind down by approximately 25%. Note that you > cannot specify <option>--cache-sim=no</option> > and <option>--branch-sim=no</option> > together, as that would leave Cachegrind with no > information to collect.</para> > > Which seems untrue now that both --cache-sim= and --branch-sim= > default to no. > True, I will update that. Nick |
|
From: Mark W. <ma...@so...> - 2023-04-15 01:49:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=53834800424510b177c59d097c3a51a66bbaf659 commit 53834800424510b177c59d097c3a51a66bbaf659 Author: Mark Wielaard <ma...@kl...> Date: Sat Apr 15 03:49:15 2023 +0200 Set version to 3.21.0-RC1 Diff: --- NEWS | 2 +- configure.ac | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index e8225fdd40..a8ab817e17 100644 --- a/NEWS +++ b/NEWS @@ -157,7 +157,7 @@ To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX where XXXXXX is the bug number as listed above. -(3.21.0.RC1: ?? Apr 2023) +(3.21.0.RC1: 14 Apr 2023) Release 3.20.0 (24 Oct 2022) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/configure.ac b/configure.ac index 80bdbb417c..66437a8000 100755 --- a/configure.ac +++ b/configure.ac @@ -17,8 +17,8 @@ m4_define([v_major_ver], [3]) m4_define([v_minor_ver], [21]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], [GIT]) -m4_define([v_rel_date], ["?? Apr 2023"]) +m4_define([v_suffix_ver], [RC1]) +m4_define([v_rel_date], ["14 Apr 2023"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], |
|
From: Mark W. <ma...@kl...> - 2023-04-15 01:01:02
|
Hi Nick,
On Wed, Apr 12, 2023 at 03:48:15AM +0000, Nicholas Nethercote wrote:
> Make `--cache-sim=no` the default for Cachegrind.
>
> Also, don't print cache simulation details in the `desc:` line when the
> cache simulation is disabled.
>
> Docs changes are yet to come.
When you add the doc changes could you also add a NEWS entry?
Note that under --branch-sim=no|yes [no] cachegrind/docs/cg-manual.xml
says:
<para>Enables or disables collection of branch instruction and
misprediction counts. By default this is disabled as it
slows Cachegrind down by approximately 25%. Note that you
cannot specify <option>--cache-sim=no</option>
and <option>--branch-sim=no</option>
together, as that would leave Cachegrind with no
information to collect.</para>
Which seems untrue now that both --cache-sim= and --branch-sim=
default to no.
Thanks,
Mark
|
|
From: Mark W. <ma...@so...> - 2023-04-14 23:04:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=68cf3b5dbfecb96c618c371359000daaaf4293b5 commit 68cf3b5dbfecb96c618c371359000daaaf4293b5 Author: Mark Wielaard <ma...@kl...> Date: Sat Apr 15 01:04:23 2023 +0200 Add bug 467036 Add time cost statistics for Regtest to NEWS Diff: --- NEWS | 1 + 1 file changed, 1 insertion(+) diff --git a/NEWS b/NEWS index 6d93d2603e..e8225fdd40 100644 --- a/NEWS +++ b/NEWS @@ -146,6 +146,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 464969 D language demangling 465435 m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed. 466104 aligned_alloc problems, part 1 +467036 Add time cost statistics for Regtest 467482 Build failure on aarch64 Alpine 467714 fdleak_* and rlimit tests fail when parent process has more than 64 descriptors opened |
|
From: Mark W. <ma...@so...> - 2023-04-14 23:02:09
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f7ddfc7cfd750978f405d7e2be8f76412fd1653d commit f7ddfc7cfd750978f405d7e2be8f76412fd1653d Author: Mark Wielaard <ma...@kl...> Date: Sat Apr 15 00:59:26 2023 +0200 Regtest: add time cost statistics Add running time of each (sub) directory in seconds https://bugs.kde.org/show_bug.cgi?id=467036 Contributed-by: Jojo R <rj...@li...> Diff: --- tests/vg_regtest.in | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tests/vg_regtest.in b/tests/vg_regtest.in index 0fe63411a1..7152765ed7 100755 --- a/tests/vg_regtest.in +++ b/tests/vg_regtest.in @@ -641,6 +641,7 @@ sub test_one_dir($$) my @fs = glob "*"; my $found_tests = (0 != (grep { $_ =~ /\.vgtest$/ } @fs)); + my $tests_start_time = time; if ($found_tests) { print "-- Running tests in $full_dir $dashes\n"; } @@ -652,7 +653,11 @@ sub test_one_dir($$) } } if ($found_tests) { - print "-- Finished tests in $full_dir $dashes\n"; + my $tests_cost_time = time - $tests_start_time; + my $end_time = "(in $tests_cost_time sec)"; + my $end_dashes = "-" x (50 - (length $full_dir) + - (length $end_time) - 1); + print "-- Finished tests in $full_dir $end_time $end_dashes\n"; } chdir(".."); |
|
From: Mark W. <ma...@so...> - 2023-04-14 22:15:16
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=16be0ca4ba53154642bd45e6aa60ffba57369a0c commit 16be0ca4ba53154642bd45e6aa60ffba57369a0c Author: Mark Wielaard <ma...@kl...> Date: Sat Apr 15 00:13:57 2023 +0200 tests fdleak.h close all open file descriptors > 2 Use sysconf (_SC_OPEN_MAX) to find the upper limit. Or use 1024 if that fails. https://bugs.kde.org/show_bug.cgi?id=467714 Diff: --- NEWS | 2 ++ none/tests/fdleak.h | 12 +++++++++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 13efee7d4a..6d93d2603e 100644 --- a/NEWS +++ b/NEWS @@ -147,6 +147,8 @@ are not entered into bugzilla tend to get forgotten about or ignored. 465435 m_libcfile.c:66 (vgPlain_safe_fd): Assertion 'newfd >= VG_(fd_hard_limit)' failed. 466104 aligned_alloc problems, part 1 467482 Build failure on aarch64 Alpine +467714 fdleak_* and rlimit tests fail when parent process has more than + 64 descriptors opened 467839 Gdbserver: Improve compatibility of library directory name n-i-bz FreeBSD rfork syscall fail with EINVAL or ENOSYS rather than VG_(unimplemented) diff --git a/none/tests/fdleak.h b/none/tests/fdleak.h index 66fd84e96f..c94dbde319 100644 --- a/none/tests/fdleak.h +++ b/none/tests/fdleak.h @@ -2,6 +2,7 @@ #define _FDLEAK_H_ #include <stdlib.h> +#include <unistd.h> #include <stdio.h> #define DO(op) \ @@ -23,6 +24,15 @@ * - For Ubuntu 8.04, see also * https://bugs.launchpad.net/ubuntu/+source/seahorse/+bug/235184 */ -#define CLOSE_INHERITED_FDS { int i; for (i = 3; i < 64; i++) close(i); } +static inline void close_inherited () { + int i; int max_fds = sysconf (_SC_OPEN_MAX); + if (max_fds < 0) + max_fds = 1024; /* Fallback if sysconf fails, returns -1. */ + + /* Only leave 0 (stdin), 1 (stdout) and 2 (stderr) open. */ + for (i = 3; i < max_fds; i++) + close(i); +} +#define CLOSE_INHERITED_FDS close_inherited () #endif /* _FDLEAK_H_ */ |