You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
|
From: Mark W. <ma...@kl...> - 2023-04-26 19:37:31
|
Hi, On Wed, 2023-04-26 at 13:41 +0200, Paul Floyd wrote: > On 25-04-23 17:28, Alexandra Hájková wrote: > > when waiting for valgrind to start. > > Would you like this to go in before 3.21 ships? This would be nice to get in before the release because it makes the vgdb --wait argument work correctly for --multi mode. I double checked the patch and it looks good to me. So pushed. Thanks, Mark |
|
From: Mark W. <ma...@so...> - 2023-04-26 19:37:18
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=476d036084139e5a070d016d0799b552c5431ac0 commit 476d036084139e5a070d016d0799b552c5431ac0 Author: Alexandra Hájková <aha...@re...> Date: Tue Apr 25 17:28:52 2023 +0200 vgdb: Use --wait argument in multi mode when waiting for valgrind to start. Diff: --- coregrind/vgdb.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index 21e67c65b7..8ec4240770 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -178,14 +178,20 @@ void add_written(int nrw) static int shared_mem_fd = -1; static -void map_vgdbshared(char* shared_mem) +void map_vgdbshared(char* shared_mem, int check_trials) { struct stat fdstat; void **s; int tries = 50; int err; - /* valgrind might still be starting up, give it 5 seconds. */ + /* valgrind might still be starting up, give it 5 seconds by + * default, or check_trails seconds if it is set by --wait + * to more than a second. */ + if (check_trials > 1) { + DEBUG(1, "check_trials %d\n", check_trials); + tries = check_trials * 10; + } do { shared_mem_fd = open(shared_mem, O_RDWR | O_CLOEXEC); err = errno; @@ -581,7 +587,7 @@ void wait_for_gdb_connect(int in_port) /* prepares the FIFOs filenames, map the shared memory. */ static -void prepare_fifos_and_shared_mem(int pid) +void prepare_fifos_and_shared_mem(int pid, int check_trials) { const HChar *user, *host; unsigned len; @@ -610,7 +616,7 @@ void prepare_fifos_and_shared_mem(int pid) DEBUG(1, "vgdb: using %s %s %s\n", from_gdb_to_pid, to_gdb_from_pid, shared_mem); - map_vgdbshared(shared_mem); + map_vgdbshared(shared_mem, check_trials); } static void @@ -1303,7 +1309,7 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir, /* Do multi stuff. */ static -void do_multi_mode(void) +void do_multi_mode(int check_trials) { char *buf = vmalloc(PBUFSIZ+1); char *q_buf = vmalloc(PBUFSIZ+1); //save the qSupported packet sent by gdb @@ -1458,7 +1464,7 @@ void do_multi_mode(void) if (res == 0) { // Lets report we Stopped with SIGTRAP (05). send_packet ("S05", noackmode); - prepare_fifos_and_shared_mem(valgrind_pid); + prepare_fifos_and_shared_mem(valgrind_pid, check_trials); DEBUG(1, "from_gdb_to_pid %s, to_gdb_from_pid %s\n", from_gdb_to_pid, to_gdb_from_pid); // gdb_relay is an endless loop till valgrind quits. @@ -2392,7 +2398,8 @@ int main(int argc, char** argv) if (!multi_mode) { pid = search_arg_pid(arg_pid, check_trials, show_list); - prepare_fifos_and_shared_mem(pid); + /* We pass 1 for check_trails here, because search_arg_pid already waited. */ + prepare_fifos_and_shared_mem(pid, 1); } else { pid = 0; } @@ -2413,7 +2420,9 @@ int main(int argc, char** argv) } if (multi_mode) { - do_multi_mode (); + /* check_trails is the --wait argument in seconds, defaulting to 1 + * if not given. */ + do_multi_mode (check_trials); } else if (last_command >= 0) { standalone_send_commands(pid, last_command, commands); } else { |
|
From: Mark W. <ma...@so...> - 2023-04-26 19:37:14
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f83f269dd15d7c006ff6b1ecb562f8bd53560a5c commit f83f269dd15d7c006ff6b1ecb562f8bd53560a5c Author: Mark Wielaard <ma...@kl...> Date: Wed Apr 26 21:31:13 2023 +0200 Fix typos in NEWS and valgrind-monitor-def.py NEWS: who_point_at -> who_points_at valgrind-monitor-def.py: MEN -> LEN Diff: --- NEWS | 2 +- coregrind/m_gdbserver/valgrind-monitor-def.py | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 7974f0c2e9..d9e04ab823 100644 --- a/NEWS +++ b/NEWS @@ -26,7 +26,7 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. to pass it to a subsequent monitor command, the GDB front end command will evaluate the address argument. It is for example possible to do: - (gdb) memcheck who_point_at &some_struct sizeof(some_struct) + (gdb) memcheck who_points_at &some_struct sizeof(some_struct) instead of: (gdb) p &some_struct $2 = (some_struct_type *) 0x1130a0 <some_struct> diff --git a/coregrind/m_gdbserver/valgrind-monitor-def.py b/coregrind/m_gdbserver/valgrind-monitor-def.py index da617cb850..b4e7b992dc 100644 --- a/coregrind/m_gdbserver/valgrind-monitor-def.py +++ b/coregrind/m_gdbserver/valgrind-monitor-def.py @@ -717,7 +717,7 @@ where HEUR is one of: @Vinit("memcheck", "who_points_at", gdb.COMMAND_DATA, gdb.COMPLETE_EXPRESSION, False) class Memcheck_Who_Points_At_Command(Valgrind_ADDR_LEN_opt): """Show places pointing inside LEN (default 1) bytes at ADDR. -Usage: memcheck who_points_at ADDR [MEN] +Usage: memcheck who_points_at ADDR [LEN] With LEN 1, only shows "start pointers" pointing exactly to ADDR. With LEN > 1, will also show "interior pointers" ADDR is an address expression evaluated by GDB. |
|
From: Bart V. A. <bva...@ac...> - 2023-04-26 14:04:45
|
On 4/26/23 03:32, Nicholas Nethercote wrote:
> As I understand it, there are two main objections to mass-reformatting.
>
> * It breaks `git blame`. But as we've seen, this is entirely fixable.
> * "If it ain't broken, don't fix it." But I argue that it the
> current inconsistent formatting is a form of brokenness. Of course
> some care is required to fix it, e.g. the particular style should
> be chosen with care, and diffs should be reviewed by humans and
> not just blindly accepted. But there are high-quality, widely-used
> tools that make it straightforward. We should use them.
>
Are these the only disadvantages of reformatting the entire code base? I
see more disadvantages:
* Preserving the formatting of code that is in tabular format requires
manual annotation (/* clang-format off */ and /* clang-format on
*/). Who will do the tedious work of reviewing the entire code base
and annotating all the code for which formatting should be preserved?
* It is a certainty that reformatting the code with clang-format will
make formatting worse for a significant fraction of the code base. A
summary of the formatting made worse by clang-format for one
particular Linux kernel source file is available here: /Re: [PATCH]
scsi: megaraid: cleanup formatting of megaraid
<https://lore.kernel.org/linux-scsi/CAKwvOdnWHVV+3s8SO=Q8F...@ma.../>/.
* It is likely that the Valgrind .clang-format file will be modified
in the future. The Linux kernel .clang-format style file was
introduced in 2018 and since then has been modified 44 times:
$ git log .clang-format | grep -c ^commit
45
Will the entire Valgrind code base be reformatted every time the
Valgrind .clang-format file is modified?
Is the above list complete? Did I perhaps overlook any disadvantages?
Bart.
|
|
From: Paul F. <pj...@wa...> - 2023-04-26 11:58:14
|
On 26-04-23 12:32, Nicholas Nethercote wrote: > > > As I understand it, there are two main objections to mass-reformatting. > > * It breaks `git blame`. But as we've seen, this is entirely fixable. > * "If it ain't broken, don't fix it." But I argue that it the current > inconsistent formatting is a form of brokenness. Of course some care > is required to fix it, e.g. the particular style should be chosen > with care, and diffs should be reviewed by humans and not just > blindly accepted. But there are high-quality, widely-used tools that > make it straightforward. We should use them. Hi Nick I'm much more in favour if the git blame history is maintained. Wrong indentation can be a source of errors. I haven't seen any in the Valgrind source, but more often these days I see "python++" code (C or C++ code that looks like Python). This is the one place where you need to be careful reviewing the diffs. (clang-tidy nags about this as well). A+ Paul |
|
From: Paul F. <pj...@wa...> - 2023-04-26 11:41:23
|
On 25-04-23 17:28, Alexandra Hájková wrote: > when waiting for valgrind to start. Hi Alexandra Would you like this to go in before 3.21 ships? A+ Paul |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-26 10:32:26
|
On Sun, 23 Apr 2023 at 03:44, Mark Wielaard <ma...@kl...> wrote: > > But why do you want to reformat all the existing code? > Isn't it enough if people have easy tools to format new hunks? > > I am happy if we encourage people to use code formatters for > new/changed code. But forcing a reformat of the whole project on > people seems like a bad idea. > > I think Paul's recent accident with clang-format shows why it is not a > good idea to try to reformat any existing code. It just introduces > huge arbitrary changes. > They are not arbitrary changes, they are improvements. Auto-formatting the whole codebase has some major advantages. - Simplicity. "Format all C code with clang-format" is simpler than "Format new C code with clang-format, but leave old C code alone." And partial application can lead to weird results when you make a change that results in a tight interleaving of changed and unchanged lines. - Consistency. Instead of a mishmash of styles, everything is consistent. `foo ( bar )` vs `foo(bar)` is one prime example of an existing inconsistency, with both versions appearing all over the place. It makes me grumpy. - Readability. A lot of the current style choices are just bad. Some of the worst problems can't be fixed in a piecemeal fashion, e.g. three space indents are weird and terrible. There are some implicit principles that inform my opinions here. - The latest revision of the code is the most important revision. This means it's worth making changes to improve things. - Developer experience is important. Code should be enjoyable to work on. There are many aspects to this, and code formatting is one of them. "It's always been like this" is a weak justification for many things. As I understand it, there are two main objections to mass-reformatting. - It breaks `git blame`. But as we've seen, this is entirely fixable. - "If it ain't broken, don't fix it." But I argue that it the current inconsistent formatting is a form of brokenness. Of course some care is required to fix it, e.g. the particular style should be chosen with care, and diffs should be reviewed by humans and not just blindly accepted. But there are high-quality, widely-used tools that make it straightforward. We should use them. Nick |
|
From: Nicholas N. <nj...@so...> - 2023-04-26 07:00:58
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=15313a558081755a783dcf2e3db0e155b3b4fbd2 commit 15313a558081755a783dcf2e3db0e155b3b4fbd2 Author: Nicholas Nethercote <n.n...@gm...> Date: Wed Apr 26 17:00:32 2023 +1000 Clarify try push instructions. Diff: --- README_DEVELOPERS | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/README_DEVELOPERS b/README_DEVELOPERS index 979ee13b4a..5b93b1c870 100644 --- a/README_DEVELOPERS +++ b/README_DEVELOPERS @@ -87,26 +87,21 @@ To get commit access to the valgrind git repository on sourceware you will have to ask an existing developer and fill in the following form: https://sourceware.org/cgi-bin/pdw/ps_form.cgi -Every developer with commit access can use try branches. Code committed -to a try branch will be build by the buildbot at builder.sourceware.org -https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try +Every developer with commit access can use try branches. If you want to try a +branch before pushing you can push to a special named try branch as follows: -If you want to try a commit you can push to a special named try branch -(users/<your-user-name>/try-<your-branch>) as follows: + git push origin $BRANCH:users/$USERNAME/try-$BRANCH - git checkout -b <your-branch> - ...hack, hack, hack... OK, looks good to submit - git commit -a -m "Awesome hack" - git push origin <your-branch>:users/<your-user-name>/try-<your-branch> +Where $BRANCH is the branch name and $USERNAME is your user name. -When all builders have build your patch the buildbot will sent you (or -actually the patch author) an email telling you if any builds failed and -references to all the logs. You can also find the logs and the builds here: +You can see the status of the builders here: https://builder.sourceware.org/buildbot/#/builders?tags=valgrind-try +The buildbot will also sent the patch author multiple success/failure emails. + Afterwards you can delete the branch again: - git push origin :users/username/try-<your-branch> + git push origin :users/$USERNAME/try-$BRANCH Debugging Valgrind with GDB |
|
From: Nicholas N. <nj...@so...> - 2023-04-26 06:54:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=ca5486d60ca49420749ff02cf241e0be4b206351 commit ca5486d60ca49420749ff02cf241e0be4b206351 Author: Nicholas Nethercote <n.n...@gm...> Date: Wed Apr 26 16:11:26 2023 +1000 Add a .git-blame-ignore-revs file. This prevents large-scale changes (e.g. auto-formatting) from negatively affecting `git blame`. Diff: --- .git-blame-ignore-revs | 5 +++++ autogen.sh | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/.git-blame-ignore-revs b/.git-blame-ignore-revs new file mode 100644 index 0000000000..d0d7ea1a1b --- /dev/null +++ b/.git-blame-ignore-revs @@ -0,0 +1,5 @@ +# 2023-04-22: clang-format was run accidentally on a few files. +bf347551c99313a4af9c38bdeda9b946c9795945 + +# 2023-04-22: Revert bf347551c99313a4af9c38bdeda9b946c9795945. +76d6b4591a5a05e43e1a819bf630c0d8ee857a7e diff --git a/autogen.sh b/autogen.sh index 117462c7ff..27f54f7d62 100755 --- a/autogen.sh +++ b/autogen.sh @@ -15,3 +15,7 @@ run aclocal run autoheader run automake -a run autoconf + +# Valgrind-specific Git configuration. +echo "running: git configuration" +git config blame.ignoreRevsFile .git-blame-ignore-revs |
|
From: Alexandra H. <aha...@re...> - 2023-04-25 15:29:08
|
when waiting for valgrind to start.
---
coregrind/vgdb.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c
index 21e67c65b..8ec424077 100644
--- a/coregrind/vgdb.c
+++ b/coregrind/vgdb.c
@@ -178,14 +178,20 @@ void add_written(int nrw)
static int shared_mem_fd = -1;
static
-void map_vgdbshared(char* shared_mem)
+void map_vgdbshared(char* shared_mem, int check_trials)
{
struct stat fdstat;
void **s;
int tries = 50;
int err;
- /* valgrind might still be starting up, give it 5 seconds. */
+ /* valgrind might still be starting up, give it 5 seconds by
+ * default, or check_trails seconds if it is set by --wait
+ * to more than a second. */
+ if (check_trials > 1) {
+ DEBUG(1, "check_trials %d\n", check_trials);
+ tries = check_trials * 10;
+ }
do {
shared_mem_fd = open(shared_mem, O_RDWR | O_CLOEXEC);
err = errno;
@@ -581,7 +587,7 @@ void wait_for_gdb_connect(int in_port)
/* prepares the FIFOs filenames, map the shared memory. */
static
-void prepare_fifos_and_shared_mem(int pid)
+void prepare_fifos_and_shared_mem(int pid, int check_trials)
{
const HChar *user, *host;
unsigned len;
@@ -610,7 +616,7 @@ void prepare_fifos_and_shared_mem(int pid)
DEBUG(1, "vgdb: using %s %s %s\n",
from_gdb_to_pid, to_gdb_from_pid, shared_mem);
- map_vgdbshared(shared_mem);
+ map_vgdbshared(shared_mem, check_trials);
}
static void
@@ -1303,7 +1309,7 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir,
/* Do multi stuff. */
static
-void do_multi_mode(void)
+void do_multi_mode(int check_trials)
{
char *buf = vmalloc(PBUFSIZ+1);
char *q_buf = vmalloc(PBUFSIZ+1); //save the qSupported packet sent by gdb
@@ -1458,7 +1464,7 @@ void do_multi_mode(void)
if (res == 0) {
// Lets report we Stopped with SIGTRAP (05).
send_packet ("S05", noackmode);
- prepare_fifos_and_shared_mem(valgrind_pid);
+ prepare_fifos_and_shared_mem(valgrind_pid, check_trials);
DEBUG(1, "from_gdb_to_pid %s, to_gdb_from_pid %s\n",
from_gdb_to_pid, to_gdb_from_pid);
// gdb_relay is an endless loop till valgrind quits.
@@ -2392,7 +2398,8 @@ int main(int argc, char** argv)
if (!multi_mode) {
pid = search_arg_pid(arg_pid, check_trials, show_list);
- prepare_fifos_and_shared_mem(pid);
+ /* We pass 1 for check_trails here, because search_arg_pid already waited. */
+ prepare_fifos_and_shared_mem(pid, 1);
} else {
pid = 0;
}
@@ -2413,7 +2420,9 @@ int main(int argc, char** argv)
}
if (multi_mode) {
- do_multi_mode ();
+ /* check_trails is the --wait argument in seconds, defaulting to 1
+ * if not given. */
+ do_multi_mode (check_trials);
} else if (last_command >= 0) {
standalone_send_commands(pid, last_command, commands);
} else {
--
2.39.2
|
|
From: Paul F. <pa...@so...> - 2023-04-25 05:37:23
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=8f1e09be1634274654217fa095afcc6d83fa8e35 commit 8f1e09be1634274654217fa095afcc6d83fa8e35 Author: Paul Floyd <pj...@wa...> Date: Tue Apr 25 07:36:10 2023 +0200 Add new DHAT userreqs to NEWS Diff: --- NEWS | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS b/NEWS index f29c756e49..7974f0c2e9 100644 --- a/NEWS +++ b/NEWS @@ -132,6 +132,12 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. - Valgrind now contains python code that defines GDB massif front end monitor commands. See CORE CHANGES. +* DHAT: + - A new kind of user request has been added which allows you to + override the 1024 byte limit on access count histograms for blocks + of memories. Two client requests are available, + DHAT_HISTOGRAM_MEMORY_UNINIT and DHAT_HISTOGRAM_MEMORY_INIT. + * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" |
|
From: Carl L. <ce...@us...> - 2023-04-24 21:29:35
|
Mark:
Thanks for the pointer on IRC chat to the RC2 tarball. I must have
missed the email.
I noticed the following message on a Power 10 system.
./autogen.sh
running: aclocal
running: autoheader
running: automake -a
Unescaped left brace in regex is passed through in regex; marked by <--
HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /home/carll/bin/automake
line 3936.
running: autoconf
The autoconf version is:
autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
Note the autoconf seemed to work ok. I was still able to configure and
build Valgrind and run the testsuite.
The test failures on Power 10 that I saw on one of the Power 10 systems
was fixed, as expected.
I see the following on both Power 10 systems.
== 714 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures,
0 stdoutB failures, 2 post failures ==
memcheck/tests/bug340392 (stderr)
memcheck/tests/linux/rfcomm (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
The results on Power 9 and Power 8 are fine as well.
Other than the autoconf message, the RC2 testing looks good on Power.
Note, the autoconf issue doesn't seem to impact the ability to
configure and run Valgrind.
Carl
|
|
From: Paul F. <pa...@so...> - 2023-04-24 18:56:50
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f86aee65ce5086245bb88c7390e409b6271bf917 commit f86aee65ce5086245bb88c7390e409b6271bf917 Author: Paul Floyd <pj...@wa...> Date: Mon Apr 24 20:56:16 2023 +0200 Fix spelling in NEWS Diff: --- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 35a9ce3cd2..f29c756e49 100644 --- a/NEWS +++ b/NEWS @@ -52,7 +52,7 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. - free the memory like free() and return NULL (GNU libc and ptmalloc). - either free the memory and then allocate a - minumum siized block or just return the + minimum sized block or just return the original pointer. Return NULL if the allocation of the minimum sized block fails (jemalloc, musl, snmalloc, Solaris, macOS). |
|
From: Paul F. <pa...@so...> - 2023-04-24 18:53:42
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=402d720b3890c5515cc75fa5b9343b620cffc375 commit 402d720b3890c5515cc75fa5b9343b620cffc375 Author: Paul Floyd <pj...@wa...> Date: Mon Apr 24 20:53:13 2023 +0200 Add memfd_create.stderr.exp-fcntl64 to EXTRA_DIST Diff: --- memcheck/tests/linux/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/memcheck/tests/linux/Makefile.am b/memcheck/tests/linux/Makefile.am index 2c49b575ba..98decb79e1 100644 --- a/memcheck/tests/linux/Makefile.am +++ b/memcheck/tests/linux/Makefile.am @@ -17,6 +17,7 @@ EXTRA_DIST = \ lsframe1.vgtest lsframe1.stdout.exp lsframe1.stderr.exp \ lsframe2.vgtest lsframe2.stdout.exp lsframe2.stderr.exp \ memfd_create.vgtest memfd_create.stderr.exp \ + memfd_create.stderr.exp-fcntl64 \ rfcomm.vgtest rfcomm.stderr.exp \ sigqueue.vgtest sigqueue.stderr.exp \ stack_changes.stderr.exp stack_changes.stdout.exp \ |
|
From: Mark W. <ma...@so...> - 2023-04-24 13:02:02
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=e896406e15cf5f631171b0afec9e0c92fc27acd3 commit e896406e15cf5f631171b0afec9e0c92fc27acd3 Author: Mark Wielaard <ma...@kl...> Date: Mon Apr 24 14:35:21 2023 +0200 Add a memfd_create.stderr.exp-fcntl64 variant On 32bit systems a glibc fcntl call results in a fcntl64 syscall. Diff: --- memcheck/tests/linux/memfd_create.stderr.exp-fcntl64 | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/memcheck/tests/linux/memfd_create.stderr.exp-fcntl64 b/memcheck/tests/linux/memfd_create.stderr.exp-fcntl64 new file mode 100644 index 0000000000..7155ddf7a1 --- /dev/null +++ b/memcheck/tests/linux/memfd_create.stderr.exp-fcntl64 @@ -0,0 +1,6 @@ +Syscall param fcntl64(arg) contains uninitialised byte(s) + ... + by 0x........: main (memfd_create.c:72) + Uninitialised value was created by a client request + at 0x........: main (memfd_create.c:71) + |
|
From: Nicholas N. <n.n...@gm...> - 2023-04-23 22:39:50
|
On Sun, 23 Apr 2023 at 03:25, Mark Wielaard <ma...@kl...> wrote: > > > > You can send up a .gitconfig for the project, so it'll work automatically > > for everyone. > > How? > We would have a file, called `.git-blame-ignore-revs` by convention. Here's an example that hides the auto-formatting/unformatting that Paul accidentally committed recently: # Accidental clang-format on a few files, 2023-04-22. > bf347551c99313a4af9c38bdeda9b946c9795945 > > # Undo the previous commit, 2023-04-22. > 76d6b4591a5a05e43e1a819bf630c0d8ee857a7e > I tested this out, it works well. Here is the vanilla blame for a couple of lines in `memcheck/mc_main.c` that were affected: 76d6b4591a (Paul Floyd 2023-04-22 16:29:27 +0200 60) static void > ocache_sarp_Set_Origins ( Addr, UWord, UInt ); /* fwds */ > 76d6b4591a (Paul Floyd 2023-04-22 16:29:27 +0200 61) static > void ocache_sarp_Clear_Origins ( Addr, UWord ); /* fwds */ > and here is the blame using the `.git-blame-ignore-revs` file: afebe61b37 (Nicholas Nethercote 2002-09-23 09:36:25 +0000 60) static void > ocache_sarp_Set_Origins ( Addr, UWord, UInt ); /* fwds */ > 4cae5c3ed5 (Julian Seward 2008-05-01 20:24:26 +0000 61) static > void ocache_sarp_Clear_Origins ( Addr, UWord ); /* fwds */ > To make that work seamlessly with `git blame` requires running `git config blame.ignoreRevsFile .git-blame-ignore-revs` once per cloned repository. That command could easily be put somewhere that will always run while building. Somewhere in `configure.ac` seems like a logical place though I'd be happy to hear suggestions otherwise. Firefox's `.git-blame-ignore-revs` file is here: https://searchfox.org/mozilla-central/source/.git-blame-ignore-revs. It has hundreds of entries! I expect/hope we wouldn't need anything like that many, but it shows that the solution scales nicely to very large codebases. The end result is that the effect of auto-formatting on history can be worked around in a straightforward manner. (BTW, we could take advantage of `configure.ac` to set up other git aliases. E.g. we could have one for pushing to a try branch, so you just have to run `git vgtry $BRANCH` instead of `git push origin $BRANCH:users/$USERNAME/try-$BRANCH`.) I can see how it would work nicely for new python code. gdb also uses > python black (plus a buildbot checker) to auto-format their python > code. If you like we could add the same to the buildbot for valgrind. > Sounds great. I am all for automating this kind of thing, making it impossible to forget to do it or do it incorrectly. How exactly would it work? Would it be a post-commit check? Could we get the same check to run locally, to run pre-commit? > BTW. Trying the various formatters listed in auxprogs/pybuild.sh gives > me (pylint suggests to use a range generator instead of an array, then > black reformates the file to get everything on one line: > > - min_ofl_st_mtime_ns = min( > - [os.stat(ofl).st_mtime_ns for ofl in ofls] > - ) > + min_ofl_st_mtime_ns = min(os.stat(ofl).st_mtime_ns > for ofl in ofls) Interesting. I have black 22.6.0, what version do you have? Nick |
|
From: Paul F. <pa...@so...> - 2023-04-23 11:52:39
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=a821780d8ccbf4a1ade369d838d52486ec1571a2 commit a821780d8ccbf4a1ade369d838d52486ec1571a2 Author: Paul Floyd <pj...@wa...> Date: Sun Apr 23 13:51:37 2023 +0200 solaris: aligned allocation issues Solaris 11.3 doesn't have aligned_alloc - add a configure time test memalign does not accept either a size or an alignment of zero Diff: --- configure.ac | 1 + coregrind/m_replacemalloc/vg_replace_malloc.c | 5 +++- memcheck/tests/Makefile.am | 2 ++ .../tests/cxx17_aligned_new.stderr.exp-solaris | 30 ++++++++++++++++++++++ memcheck/tests/memalign_args.c | 2 +- memcheck/tests/memalign_args.stderr.exp-darwin | 11 ++++++++ memcheck/tests/solaris/aligned_alloc.c | 5 ++-- 7 files changed, 52 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 8470daebd1..d1af9de0d3 100755 --- a/configure.ac +++ b/configure.ac @@ -4803,6 +4803,7 @@ AC_CHECK_LIB([pthread], [pthread_create]) AC_CHECK_LIB([rt], [clock_gettime]) AC_CHECK_FUNCS([ \ + aligned_alloc \ clock_gettime\ copy_file_range \ epoll_create \ diff --git a/coregrind/m_replacemalloc/vg_replace_malloc.c b/coregrind/m_replacemalloc/vg_replace_malloc.c index 78d0b33104..a71aa4b5b2 100644 --- a/coregrind/m_replacemalloc/vg_replace_malloc.c +++ b/coregrind/m_replacemalloc/vg_replace_malloc.c @@ -1742,8 +1742,10 @@ extern int * __error(void) __attribute__((weak)); #if defined(VGO_solaris) #define VG_MEMALIGN_ALIGN_POWER_TWO 0 +#define VG_MEMALIGN_NO_ALIGN_ZERO 1 #else #define VG_MEMALIGN_ALIGN_POWER_TWO 1 +#define VG_MEMALIGN_NO_ALIGN_ZERO 0 #endif #if defined(VGO_solaris) @@ -1802,7 +1804,8 @@ extern int * __error(void) __attribute__((weak)); DO_INIT; \ MALLOC_TRACE("memalign(alignment %llu, size %llu)", \ (ULong)alignment, (ULong)size ); \ - if ((VG_MEMALIGN_NO_SIZE_ZERO && (alignment == 0)) \ + if ((VG_MEMALIGN_NO_SIZE_ZERO && (size == 0)) \ + || (VG_MEMALIGN_NO_ALIGN_ZERO && (alignment == 0)) \ || (VG_MEMALIGN_ALIGN_POWER_TWO && (alignment & (alignment - 1)) != 0) \ || (VG_MEMALIGN_ALIGN_FACTOR_FOUR && (alignment % 4 != 0))) { \ SET_ERRNO_EINVAL; \ diff --git a/memcheck/tests/Makefile.am b/memcheck/tests/Makefile.am index faf9130bcd..9bbbe7bec5 100644 --- a/memcheck/tests/Makefile.am +++ b/memcheck/tests/Makefile.am @@ -141,6 +141,7 @@ EXTRA_DIST = \ custom-overlap.stderr.exp custom-overlap.vgtest \ cxx17_aligned_new.stderr.exp cxx17_aligned_new.vgtest \ cxx17_aligned_new.stderr.exp_32 \ + cxx17_aligned_new.stderr.exp-solaris \ cxx17_aligned_new.stdout.exp \ sized_aligned_new_delete_args.stderr.exp \ sized_aligned_new_delete_args.vgtest \ @@ -226,6 +227,7 @@ EXTRA_DIST = \ memalign_test.stderr.exp-freebsd-clang \ memalign_args.vgtest memalign_args.stderr.exp \ memalign_args.stderr.exp-glibc \ + memalign_args.stderr.exp-darwin \ memcmptest.stderr.exp memcmptest.stderr.exp2 \ memcmptest.stdout.exp memcmptest.vgtest \ memmem.stderr.exp memmem.vgtest \ diff --git a/memcheck/tests/cxx17_aligned_new.stderr.exp-solaris b/memcheck/tests/cxx17_aligned_new.stderr.exp-solaris new file mode 100644 index 0000000000..54659a4dba --- /dev/null +++ b/memcheck/tests/cxx17_aligned_new.stderr.exp-solaris @@ -0,0 +1,30 @@ + +_ZnwmSt11align_val_t(size 64, al 64) = 0x........ +_ZdlPvSt11align_val_t(0x........) +_ZnamSt11align_val_t(size 320, al 64) = 0x........ +_ZdaPvSt11align_val_t(0x........) +_ZnwmSt11align_val_t(size 64, al 64) = 0x........ +_ZdlPvmSt11align_val_t(0x........) +_ZnamSt11align_val_t(size 320, al 64) = 0x........ +_ZdaPvmSt11align_val_t(0x........) +_ZnwmSt11align_val_tRKSt9nothrow_t(size 64, al 64) = 0x........ +_ZdlPvSt11align_val_tRKSt9nothrow_t(0x........) +_ZnamSt11align_val_tRKSt9nothrow_t(size 320, al 64) = 0x........ +_ZdaPvSt11align_val_tRKSt9nothrow_t(0x........) +_Znwm(4) = 0x........ +_ZdlPvSt11align_val_t(0x........) +_ZnwmRKSt9nothrow_t(4) = 0x........ +_ZdlPvm(0x........) +_Znam(20) = 0x........ +_ZdaPv(0x........) +_ZnamRKSt9nothrow_t(20) = 0x........ +_ZdaPv(0x........) + +HEAP SUMMARY: + in use at exit: ... bytes in ... blocks + total heap usage: ... allocs, ... frees, ... bytes allocated + +For a detailed leak analysis, rerun with: --leak-check=full + +For lists of detected and suppressed errors, rerun with: -s +ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) diff --git a/memcheck/tests/memalign_args.c b/memcheck/tests/memalign_args.c index de765bcc2b..6946ae3a32 100644 --- a/memcheck/tests/memalign_args.c +++ b/memcheck/tests/memalign_args.c @@ -23,7 +23,7 @@ int main(void) (void)posix_memalign((void **)&mem,align,size); free(mem); -#if !defined(VGO_darwin) +#if defined(HAVE_ALIGNED_ALLOC) p = aligned_alloc(align, size); free(p); #endif diff --git a/memcheck/tests/memalign_args.stderr.exp-darwin b/memcheck/tests/memalign_args.stderr.exp-darwin new file mode 100644 index 0000000000..c255e02f1c --- /dev/null +++ b/memcheck/tests/memalign_args.stderr.exp-darwin @@ -0,0 +1,11 @@ +Conditional jump or move depends on uninitialised value(s) + at 0x........: memalign (vg_replace_malloc.c:...) + by 0x........: main (memalign_args.c:19) + +Conditional jump or move depends on uninitialised value(s) + at 0x........: posix_memalign (vg_replace_malloc.c:...) + by 0x........: main (memalign_args.c:23) + +Conditional jump or move depends on uninitialised value(s) + at 0x........: valloc (vg_replace_malloc.c:...) + by 0x........: main (memalign_args.c:31) diff --git a/memcheck/tests/solaris/aligned_alloc.c b/memcheck/tests/solaris/aligned_alloc.c index c8e82e276f..346595f29e 100644 --- a/memcheck/tests/solaris/aligned_alloc.c +++ b/memcheck/tests/solaris/aligned_alloc.c @@ -1,12 +1,13 @@ #include <stdlib.h> #include <assert.h> #include <errno.h> +#include "../../config.h" int main(void) { +#if defined(HAVE_ALIGNED_ALLOC) char* p = NULL; - // zero size p = aligned_alloc(0, 8); assert(p == NULL && errno == EINVAL); @@ -33,6 +34,6 @@ int main(void) } assert(p == NULL && errno == ENOMEM); - +#endif } |
|
From: Paul F. <pj...@wa...> - 2023-04-22 19:22:29
|
On 22-04-23 19:44, Mark Wielaard wrote: > > But why do you want to reformat all the exiting code? > Isn't it enough if people have easy tools to format new hunks? > > I am happy if we encourage people to use code formatters for > new/changed code. But forcing a reformat of the whole project on > people seems like a bad idea. > > I think Paul's recent accident with clang-format shows why it is not a > good idea to try to reformat any existing code. It just introduces > huge arbitrary changes. The main thing for me is that the current indentation isn't too bad. Things like line breaks, continuation, align with assignment, multiple statements on a line are less consistent. That also means bigger diffs if reformatting. I wasn't expecting the diffs to be so big. For now I don't see enough benefit for large scale reformatting, but I am planning to continue using it for new blocks of code and new files. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2023-04-22 19:09:33
|
On 22-04-23 16:35, Paul Floyd wrote:
>
>
> On 22-04-23 16:25, Mark Wielaard wrote:
>
>>
>> That is one giant patch. I assume accidential?
>> It also seems to break the build.
>> Could you please revert this (minus the NEWS typo).
>
> Yes I screwed up and pushed changes from experimenting with clang-format.
>
> Wonder how it broke the build - not very encouraging.
The error was
In file included from mc_main.c:49:
../include/pub_tool_xtmemory.h:41:38: error: unknown type name
‘XT_filter_IPs_t’
41 | extern void VG_(XTMemory_Full_init) (XT_filter_IPs_t
filter_IPs_Fn);
The compilation failure was because clang-format reordered all the
headers in mc_main.c into alphabetical order.
pub_tool_xtmemory.h has a dependency upon pub_tool_xtree.h but doesn't
include it and also pub_tool_xtree.h sorts alphabetically after
pub_tool_xtmemory.h which broke the dependency.
A+
Paul
|
|
From: Mark W. <ma...@kl...> - 2023-04-22 18:30:12
|
On Sat, Apr 22, 2023 at 09:53:22AM +1000, Nicholas Nethercote wrote: > Failing to add test files to Makefile.am is a really easy mistake to make, > and one I've done multiple times recently. Mark, you've often fixed these, > how do you detect them? I did a try push beforehand and it didn't detect > the missing file. There are two ways. make regtest does a quick check. Paul pointed out that can also be triggered by make post-regtest-checks. Maybe we should make that part of make check instead? The other is make distcheck. Which creates a dist and then tries to do a buid and make check (plus a srcdir != builddir build). The fedora-latest builder actually does a make distcheck, but since make auxchecks fails there it isn't in the try builders and doesn't show up as a new failure. I'll remove the auxchecks step and add it to the try builders. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2023-04-22 17:45:20
|
Hi Nick, On Fri, Apr 21, 2023 at 09:06:06AM +1000, Nicholas Nethercote wrote: > On Fri, 21 Apr 2023 at 07:06, Bart Van Assche <bva...@ac...> wrote: > > > No matter how > > much time is spent on tuning the .clang-format file, there will always > > be code for which the formatting is made worse by clang-format than the > > existing code. > > > > It's true that there are rare cases where an auto-formatter does a bad job, > such as code in tabular form. > > Fortunately there's an easy workaround for that too: you just put `// > clang-format off` at the start of the block and `// clang-format on` at the > end of the block. But why do you want to reformat all the exiting code? Isn't it enough if people have easy tools to format new hunks? I am happy if we encourage people to use code formatters for new/changed code. But forcing a reformat of the whole project on people seems like a bad idea. I think Paul's recent accident with clang-format shows why it is not a good idea to try to reformat any existing code. It just introduces huge arbitrary changes. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2023-04-22 17:25:23
|
Hi Nick,
On Fri, Apr 21, 2023 at 06:51:42AM +1000, Nicholas Nethercote wrote:
> On Fri, 21 Apr 2023 at 06:02, Mark Wielaard <ma...@kl...> wrote:
> > Sure you can work around it, but I don't think that is a great
> > solution. It requires everyone to make some local changes.
> >
>
> You can send up a .gitconfig for the project, so it'll work automatically
> for everyone.
How? If you can install the .gitconfig automatically that would be
interesting, but I believe you'll always have to install .gitconfig
tweaks by hand.
> > I am not a fan, but also not dead against.
>
> Have you ever worked on a project that uses auto-formatting? Skepticism
> followed by enthusiasm is common. Paul, Julian, and I all have used it on
> other codebases and are now advocates. I'm using it for Cachegrind's Python
> code right now. It makes life easier.
I can see how it would work nicely for new python code. gdb also uses
python black (plus a buildbot checker) to auto-format their python
code. If you like we could add the same to the buildbot for valgrind.
BTW. Trying the various formatters listed in auxprogs/pybuild.sh gives
me (pylint suggests to use a range generator instead of an array, then
black reformates the file to get everything on one line:
diff --git a/cachegrind/cg_annotate.in b/cachegrind/cg_annotate.in
index c76a760be..cba91aec7 100755
--- a/cachegrind/cg_annotate.in
+++ b/cachegrind/cg_annotate.in
@@ -1090,9 +1090,7 @@ def print_annotated_src_files(
# mtimes as if they are all as early as the earliest one.
# Therefore, we warn only if the earliest source file is
# more recent than the cgout file.
- min_ofl_st_mtime_ns = min(
- [os.stat(ofl).st_mtime_ns for ofl in ofls]
- )
+ min_ofl_st_mtime_ns = min(os.stat(ofl).st_mtime_ns for ofl in ofls)
for cgout_filename in args.cgout_filename:
if min_ofl_st_mtime_ns > os.stat(cgout_filename).st_mtime_ns:
> Personally I am happy with emacs M-x indent-region on the code I edit.
> > There is a .dir-locals.el in git which catches some (but certainly not
> > all) formatting things.
> >
>
> What about people who don't use emacs?
:) That sound like the start of a joke... I assume other editors have
something similar to M-X ident-region. But have no experience with
that. I just mentioned it to show that I do have a little experience
with formatters and do like valgrind having a .dir-locals.el. So if
the .clang-format gives the same kind of experience to others then
that is nice.
Cheers,
Mark
|
|
From: Mark W. <ma...@kl...> - 2023-04-22 16:13:46
|
Hi Tobias, On Sat, Apr 22, 2023 at 08:28:40AM +0200, Tobias Bading wrote: > Building c8832cb2d on Ubuntu (MATE) 20.04.6 LTS with gcc 9.4.0 > (Ubuntu 9.4.0-1ubuntu1~20.04.1) produces these 3 warnings: > > vgdb.c: In function ‘do_multi_mode’: > vgdb.c:1332:11: warning: ignoring return value of ‘asprintf’, declared > with attribute warn_unused_result [-Wunused-result] > 1332 | asprintf (&reply, > | ^~~~~~~~~~~~~~~~~ > […] > 1347 | "QSetWorkingDir+", (UInt)PBUFSIZ - 1); > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > vgdb.c: In function ‘fork_and_exec_valgrind’: > vgdb.c:1228:13: warning: ignoring return value of ‘write’, declared with > attribute warn_unused_result [-Wunused-result] > 1228 | write (pipefd[1], &err, sizeof (int)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > vgdb.c:1283:7: warning: ignoring return value of ‘write’, declared with > attribute warn_unused_result [-Wunused-result] > 1283 | write (pipefd[1], &err, sizeof (int)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks for reporting. We are in trouble if these calls to asprintf or write fail and cannot do much more than exit at that point. But I fixed all three places so to explicitly check if those calls fail. > 8 bits of contribution in NEWS: > > - from different terminals. So for example to start you program > + from different terminals. So for example to start your program Thanks. Paul already fixed this. Cheers, Mark |
|
From: Mark W. <ma...@so...> - 2023-04-22 16:10:04
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=83602059684aaf92e5ac701ca4e79fe44e3d6a00 commit 83602059684aaf92e5ac701ca4e79fe44e3d6a00 Author: Mark Wielaard <ma...@kl...> Date: Sat Apr 22 18:02:25 2023 +0200 vgdb: Always check the result from asprintf and write calls Diff: --- coregrind/vgdb.c | 57 ++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/coregrind/vgdb.c b/coregrind/vgdb.c index 6e5e819563..21e67c65b7 100644 --- a/coregrind/vgdb.c +++ b/coregrind/vgdb.c @@ -1225,7 +1225,14 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir, if (chdir (working_dir) != 0) { err = errno; perror("chdir"); - write (pipefd[1], &err, sizeof (int)); + // We try to write the result to the parent, but always exit. + int written = 0; + while (written < sizeof (int)) { + int nrw = write (pipefd[1], &err, sizeof (int) - written); + if (nrw == -1) + break; + written += nrw; + } _exit (-1); } } @@ -1280,7 +1287,14 @@ int fork_and_exec_valgrind (int argc, char **argv, const char *working_dir, perror or printf in this situation since they aren't async-safe. */ // perror ("execvp valgrind"); // printf ("execve returned??? confusing: %d\n", res); - write (pipefd[1], &err, sizeof (int)); + // We try to write the result to the parent, but always exit. + int written = 0; + while (written < sizeof (int)) { + int nrw = write (pipefd[1], &err, sizeof (int) - written); + if (nrw == -1) + break; + written += nrw; + } _exit (-1); } @@ -1329,24 +1343,27 @@ void do_multi_mode(void) char *reply; strcpy(q_buf, buf); // Keep this in sync with coregrind/m_gdbserver/server.c - 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); + if (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+;" + /* Extra vgdb support before valgrind starts up. */ + "QEnvironmentHexEncoded+;" + "QEnvironmentReset+;" + "QEnvironmentUnset+;" + "QSetWorkingDir+", (UInt)PBUFSIZ - 1) != -1) { + send_packet(reply, noackmode); + free (reply); + } else { + XERROR(errno, "asprintf failed\n"); + } } else if (strncmp(STARTNOACKMODE, buf, strlen(STARTNOACKMODE)) == 0) { // We have to ack this one |
|
From: Paul F. <pj...@wa...> - 2023-04-22 14:35:31
|
On 22-04-23 16:25, Mark Wielaard wrote: > > That is one giant patch. I assume accidential? > It also seems to break the build. > Could you please revert this (minus the NEWS typo). Yes I screwed up and pushed changes from experimenting with clang-format. Wonder how it broke the build - not very encouraging. A+ Paul |