You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(6) |
|
2
(6) |
3
(9) |
4
(4) |
5
(1) |
6
|
7
|
8
|
|
9
|
10
(2) |
11
(1) |
12
(2) |
13
(4) |
14
(6) |
15
(8) |
|
16
(9) |
17
(5) |
18
(13) |
19
(6) |
20
(15) |
21
(17) |
22
(19) |
|
23
(2) |
24
(4) |
25
(2) |
26
(10) |
27
(6) |
28
(9) |
29
(3) |
|
30
|
|
|
|
|
|
|
|
From: Paul F. <pa...@so...> - 2023-04-26 20:18:14
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=11af86679796f1c099ae5f65a804b67018afaf32 commit 11af86679796f1c099ae5f65a804b67018afaf32 Author: Paul Floyd <pj...@wa...> Date: Wed Apr 26 22:17:16 2023 +0200 FreeBSD: add libc suppressions for Helgrind and DRD Diff: --- freebsd-drd.supp | 54 +++++++++++++++++++++++++++++++++++++++++-- freebsd-helgrind.supp | 64 +++++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 109 insertions(+), 9 deletions(-) diff --git a/freebsd-drd.supp b/freebsd-drd.supp index 2248389587..93ad79f4bd 100644 --- a/freebsd-drd.supp +++ b/freebsd-drd.supp @@ -31,7 +31,7 @@ { DRD-MANY1 drd:ConflictingAccess - obj:/lib/libthr.so.3 + obj:*/lib*/libthr.so.3 obj:/libexec/ld-elf*.so.1 } { @@ -52,7 +52,7 @@ { DRD-MANY4 drd:ConflictingAccess - obj:/lib/libthr.so.3 + obj:*/lib*/libthr.so.3 } { DRD-UNWIND1 @@ -190,3 +190,53 @@ drd:ConflictingAccess fun:_ZL11* } +{ + DRD-FREEBSD131-FOPEN1 + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + fun:fopen +} +{ + DRD-FREEBSD131-FOPEN2 + drd:ConflictingAccess + fun:fopen + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-FGETS + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + ... + fun:fgets +} +{ + DRD-FREEBSD131-FCLOSE + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + fun:fclose +} +{ + DRD-FREEBSD131-RES-VINIT + drd:ConflictingAccess + fun:__h_errno_set + fun:__res_vinit + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-ERRNO-SET + drd:ConflictingAccess + fun:__h_errno_set + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-LOCALECONV + drd:ConflictingAccess + fun:localeconv_l + obj:*/lib*/libc.so.7 +} +{ + DRD-FREEBSD131-VSPRINTF + drd:ConflictingAccess + obj:*/lib*/libc.so.7 + fun:vsprintf +} diff --git a/freebsd-helgrind.supp b/freebsd-helgrind.supp index 32af0a7626..be10339c62 100644 --- a/freebsd-helgrind.supp +++ b/freebsd-helgrind.supp @@ -3,7 +3,7 @@ { HELGRIND-LIBTHR1 Helgrind:Race - obj:*/lib*/libthr.so.3* + obj:*/lib*/libthr.so.3 } { HELGRIND-LIB-RTLD1 @@ -99,7 +99,7 @@ HELGRIND-PTHREAD-SELF1 Helgrind:Race fun:mythread_wrapper - obj:*/lib*/libthr.so.3* + obj:*/lib*/libthr.so.3 } { HELGRIND-SEM-CLOCKWAIT1 @@ -145,11 +145,11 @@ { HELGRIND-CXX-UNWIND Helgrind:Race - obj:/lib/libcxxrt.so.1 - obj:/lib/libthr.so.3 - obj:/lib/libthr.so.3 - obj:/lib/libthr.so.3 - obj:/lib/libgcc_s.so.1 + obj:*/lib*/libcxxrt.so.1 + obj:*/lib*/libthr.so.3 + obj:*/lib*/libthr.so.3 + obj:*/lib*/libthr.so.3 + obj:*/lib*/libgcc_s.so.1 fun:_Unwind_ForcedUnwind } { @@ -167,3 +167,53 @@ Helgrind:Race fun:_ZNSt3__119__thread_local_dataEv } +{ + HELGRIND-LIBC-FOPEN1 + Helgrind:Race + obj:*/lib*/libc.so.7 + fun:fopen +} +{ + HELGRIND-LIBC-FOPEN2 + Helgrind:Race + fun:fopen + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-FGETS + Helgrind:Race + obj:*/lib*/libc.so.7 + ... + fun:fgets +} +{ + HELGRIND-LIBC-FCLOSE + Helgrind:Race + obj:*/lib*/libc.so.7 + fun:fclose +} +{ + HELGRIND-LIBC-RES-STATE + Helgrind:Race + fun:__res_state + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-ERRNO-SET + Helgrind:Race + fun:__h_errno_set + ... + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-LOCALECONV-L + Helgrind:Race + fun:localeconv_l + obj:*/lib*/libc.so.7 +} +{ + HELGRIND-LIBC-VSPRINTF + Helgrind:Race + obj:*/lib*/libc.so.7 + fun:vsprintf +} |
|
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 |