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: Carl L. <ca...@so...> - 2022-10-31 18:29:00
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=873f3766955c4f5caacc014dbe3d4fa0a4f6f712 commit 873f3766955c4f5caacc014dbe3d4fa0a4f6f712 Author: Carl Love <ce...@us...> Date: Mon Oct 31 13:29:31 2022 -0400 Bug 444110 priv/guest_ppc_toIR.c: warning: duplicated 'if' condition The compiler reported a duplicated condition in VEX/priv/guest_ppc_toIR.c The handling of the plbz and xxpermx instructions have the same if/elseif conditions. The else if condition for the plbz instruction was wrong. The elseif statement should be checking for pType2 not pType1. The plbz instruction was inadvertently being handled by the else statement for the lbz instruction. This patch fixes the checking for the plbz and lbz instructions. Diff: --- NEWS | 1 + VEX/priv/guest_ppc_toIR.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 614ce44a36..208d8afab7 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,7 @@ bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. +444110 priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition. To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/VEX/priv/guest_ppc_toIR.c b/VEX/priv/guest_ppc_toIR.c index 41d7bf65c0..16181768e4 100644 --- a/VEX/priv/guest_ppc_toIR.c +++ b/VEX/priv/guest_ppc_toIR.c @@ -36012,11 +36012,11 @@ DisResult disInstr_PPC_WRK ( // splat instructions: xxpermx if (dis_vector_permute_prefix( prefix, theInstr, abiinfo )) goto decode_success; - } else if (is_prefix && ( ptype == pType1 ) ) { // plbz: load instruction + } else if (is_prefix && ( ptype == pType2 ) ) { // plbz: load instruction if ( !(allow_isa_3_1) ) goto decode_noIsa3_1; if (dis_int_load_prefix( prefix, theInstr )) goto decode_success; - } else { // lbz: load instruction + } else if (!is_prefix) { // lbz: load instruction if (dis_int_load_prefix( prefix, theInstr )) goto decode_success; } |
|
From: Paul F. <pa...@so...> - 2022-10-28 18:20:59
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=6c9aae8f44c50b7949a7a6ed923410eb9c13e9e9 commit 6c9aae8f44c50b7949a7a6ed923410eb9c13e9e9 Author: Paul Floyd <pj...@wa...> Date: Fri Oct 28 22:19:47 2022 +0200 FreeBSD: more filtering for gdbserver_tests/nlvgdbsigqueue Needed for FreeBSD 14 without debug info files. Diff: --- gdbserver_tests/filter_gdb.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gdbserver_tests/filter_gdb.in b/gdbserver_tests/filter_gdb.in index b753e01688..04a56fdef1 100755 --- a/gdbserver_tests/filter_gdb.in +++ b/gdbserver_tests/filter_gdb.in @@ -119,6 +119,7 @@ s/\(0x........\) in ?? ()$/\1 in syscall .../ # return SYSCALL_CANCEL.... s/in __select .*/in syscall .../ s/in __select$/in syscall .../ +s/in _select ()/in syscall .../ /nfds=/d /exceptfds=/d /timeout=/d @@ -135,6 +136,7 @@ s/in \(.__\)\{0,1\}select () from \/.*$/in syscall .../ /^ from \/lib64\/libc.so.*$/d /^ from \/lib64\/.*\/libc.so.*$/d /^ from \/lib64\/.*\/libc-.*.so/d +s/ from \/lib\/libc\.so.*// # and yet another (gdb 7.0 way) to get a system call s/in select ()$/in syscall .../ |
|
From: Paul F. <pa...@so...> - 2022-10-28 15:05:25
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=aed1e501c8cd40be23e57c3ad7b086ddae9a6c66 commit aed1e501c8cd40be23e57c3ad7b086ddae9a6c66 Author: Paul Floyd <pj...@wa...> Date: Fri Oct 28 17:04:26 2022 +0200 FreeBSD: fix a typo in my previous commit for VKI_AT_USRSTACKLIM define. Diff: --- include/vki/vki-freebsd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/vki/vki-freebsd.h b/include/vki/vki-freebsd.h index 7f32c9cf86..72633d471d 100644 --- a/include/vki/vki-freebsd.h +++ b/include/vki/vki-freebsd.h @@ -2517,7 +2517,7 @@ struct vki_ps_strings { #define VKI_AT_KPRELOAD 34 /* added in FreeBSD 14 */ #define VKI_AT_USRSTACKBASE 35 -#define VKI_T_USRSTACKLIM 36 +#define VKI_AT_USRSTACKLIM 36 /* AT_COUNT depends on the FreeBSD version, not currently used */ |
|
From: Paul F. <pa...@so...> - 2022-10-28 14:54:31
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=4ff2185f4590b7850de138270b8a0dfdc3ae6c6b commit 4ff2185f4590b7850de138270b8a0dfdc3ae6c6b Author: Paul Floyd <pj...@wa...> Date: Fri Oct 28 16:52:50 2022 +0200 FreeBSD: remove dependency on elf header and make VKI_ copies of AT defines Also prepare NEWS and configure.ac for 3.21.0 Diff: --- NEWS | 29 +++++++++++ configure.ac | 6 +-- coregrind/m_initimg/initimg-freebsd.c | 92 ++++++++++++++++------------------- include/vki/vki-freebsd.h | 41 ++++++++++++++++ 4 files changed, 116 insertions(+), 52 deletions(-) diff --git a/NEWS b/NEWS index 029161cc67..614ce44a36 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,32 @@ +Release 3.21.0 (?? Apr 2023) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, +PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, +MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, +X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and +AMD64/FreeBSD. There is also preliminary support for X86/macOS 10.13, +AMD64/macOS 10.13 and nanoMIPS/Linux. + +* ==================== CORE CHANGES =================== + + +* ==================== FIXED BUGS ==================== + +The following bugs have been fixed or resolved. Note that "n-i-bz" +stands for "not in bugzilla" -- that is, a bug that was reported to us +but never got a bugzilla entry. We encourage you to file bugs in +bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather +than mailing the developers (or mailing lists) directly -- bugs that +are not entered into bugzilla tend to get forgotten about or ignored. + + +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) + Release 3.20.0 (24 Oct 2022) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/configure.ac b/configure.ac index 4a3f3db22d..41047dc2c6 100755 --- a/configure.ac +++ b/configure.ac @@ -15,10 +15,10 @@ # Also set the (expected/last) release date here. # Do not forget to rerun ./autogen.sh m4_define([v_major_ver], [3]) -m4_define([v_minor_ver], [20]) +m4_define([v_minor_ver], [21]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], []) -m4_define([v_rel_date], ["24 Oct 2022"]) +m4_define([v_suffix_ver], [GIT]) +m4_define([v_rel_date], ["?? Apr 2023"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], diff --git a/coregrind/m_initimg/initimg-freebsd.c b/coregrind/m_initimg/initimg-freebsd.c index 8188e60d90..ece565e66d 100644 --- a/coregrind/m_initimg/initimg-freebsd.c +++ b/coregrind/m_initimg/initimg-freebsd.c @@ -52,12 +52,6 @@ #include "pub_core_pathscan.h" #include "pub_core_initimg.h" /* self */ -/* --- !!! --- EXTERNAL HEADERS start --- !!! --- */ -/* This is for ELF types etc, and also the AT_ constants. */ -#include <elf.h> -/* --- !!! --- EXTERNAL HEADERS end --- !!! --- */ - - /*====================================================================*/ /*=== Loading the client ===*/ /*====================================================================*/ @@ -439,30 +433,30 @@ Addr setup_client_stack( void* init_sp, /* now, how big is the auxv? */ auxsize = sizeof(*auxv); /* there's always at least one entry: AT_NULL */ - for (cauxv = orig_auxv; cauxv->a_type != AT_NULL; cauxv++) { + for (cauxv = orig_auxv; cauxv->a_type != VKI_AT_NULL; cauxv++) { auxsize += sizeof(*cauxv); switch(cauxv->a_type) { - case AT_EXECPATH: + case VKI_AT_EXECPATH: stringsize += VG_(strlen)(cauxv->u.a_ptr) + 1; break; - case AT_CANARYLEN: + case VKI_AT_CANARYLEN: canarylen = cauxv->u.a_val; /*VG_ROUNDUP(stringsize, sizeof(Word));*/ stringsize += canarylen; break; - case AT_PAGESIZESLEN: + case VKI_AT_PAGESIZESLEN: pagesizeslen = cauxv->u.a_val; /*VG_ROUNDUP(stringsize, sizeof(Word));*/ stringsize += pagesizeslen; break; #if 0 - case AT_TIMEKEEP: + case VKI_AT_TIMEKEEP: /*VG_ROUNDUP(stringsize, sizeof(Word));*/ stringsize += sizeof(struct vki_vdso_timehands); break; #endif #if (FREEBSD_VERS >= FREEBSD_13_0) - case AT_PS_STRINGS: + case VKI_AT_PS_STRINGS: stringsize += sizeof(struct vki_ps_strings); break; #endif @@ -622,7 +616,7 @@ Addr setup_client_stack( void* init_sp, *client_auxv = (UInt *)auxv; VG_(client_auxv) = (UWord *)*client_auxv; - for (; orig_auxv->a_type != AT_NULL; auxv++, orig_auxv++) { + for (; orig_auxv->a_type != VKI_AT_NULL; auxv++, orig_auxv++) { /* copy the entry... */ *auxv = *orig_auxv; @@ -637,49 +631,49 @@ Addr setup_client_stack( void* init_sp, */ switch(auxv->a_type) { - case AT_IGNORE: - case AT_PHENT: - case AT_PAGESZ: - case AT_FLAGS: - case AT_NOTELF: - case AT_UID: - case AT_EUID: - case AT_GID: - case AT_EGID: - case AT_STACKPROT: - case AT_NCPUS: - case AT_OSRELDATE: - case AT_PAGESIZESLEN: - case AT_CANARYLEN: + case VKI_AT_IGNORE: + case VKI_AT_PHENT: + case VKI_AT_PAGESZ: + case VKI_AT_FLAGS: + case VKI_AT_NOTELF: + case VKI_AT_UID: + case VKI_AT_EUID: + case VKI_AT_GID: + case VKI_AT_EGID: + case VKI_AT_STACKPROT: + case VKI_AT_NCPUS: + case VKI_AT_OSRELDATE: + case VKI_AT_PAGESIZESLEN: + case VKI_AT_CANARYLEN: #if (FREEBSD_VERS >= FREEBSD_11) // FreeBSD 11+ also have HWCAP and HWCAP2 - case AT_EHDRFLAGS: + case VKI_AT_EHDRFLAGS: #endif /* All these are pointerless, so we don't need to do anything about them. */ break; - case AT_EXECPATH: + case VKI_AT_EXECPATH: auxv->u.a_ptr = copy_str(&strtab, orig_auxv->u.a_ptr); break; - case AT_CANARY: + case VKI_AT_CANARY: if (canarylen >= 1) auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, canarylen); else - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; break; - case AT_PAGESIZES: + case VKI_AT_PAGESIZES: if (pagesizeslen >= 1) auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, pagesizeslen); else - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; break; #if 0 /* * @todo PJF this crashes intermittently */ - case AT_TIMEKEEP: + case VKI_AT_TIMEKEEP: auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, sizeof(struct vki_vdso_timehands)); break; #endif @@ -688,18 +682,18 @@ Addr setup_client_stack( void* init_sp, /* @todo PJF BSDFLAGS causes serveral testcases to crash. Not sure why, it seems to be used for sigfastblock */ // case AT_BSDFLAGS: - case AT_ARGC: - case AT_ENVC: + case VKI_AT_ARGC: + case VKI_AT_ENVC: break; - case AT_PS_STRINGS: + case VKI_AT_PS_STRINGS: auxv->u.a_ptr = copy_bytes(&strtab, orig_auxv->u.a_ptr, sizeof(struct vki_ps_strings)); ((struct vki_ps_strings*)auxv->u.a_ptr)->ps_envstr = (char**)VG_(client_envp); ((struct vki_ps_strings*)auxv->u.a_ptr)->ps_argvstr = (char**)client_argv; break; - case AT_ARGV: + case VKI_AT_ARGV: auxv->u.a_val = client_argv; break; - case AT_ENVV: + case VKI_AT_ENVV: auxv->u.a_val = (Word)VG_(client_envp); break; #endif @@ -714,33 +708,33 @@ Addr setup_client_stack( void* init_sp, #endif #if (FREEBSD_VERS >= FREEBSD_14) - case AT_USRSTACKBASE: + case VKI_AT_USRSTACKBASE: auxv->u.a_val = VG_(get_usrstack)(); break; - case AT_USRSTACKLIM: + case VKI_AT_USRSTACKLIM: auxv->u.a_val = clstack_max_size; break; #endif - case AT_PHDR: + case VKI_AT_PHDR: if (info->phdr == 0) - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; else auxv->u.a_val = info->phdr; break; - case AT_PHNUM: + case VKI_AT_PHNUM: if (info->phdr == 0) - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; else auxv->u.a_val = info->phnum; break; - case AT_BASE: + case VKI_AT_BASE: auxv->u.a_val = info->interp_offset; break; - case AT_ENTRY: + case VKI_AT_ENTRY: auxv->u.a_val = info->entry; break; @@ -749,12 +743,12 @@ Addr setup_client_stack( void* init_sp, VG_(debugLog)(2, "initimg", "stomping auxv entry %llu\n", (ULong)auxv->a_type); - auxv->a_type = AT_IGNORE; + auxv->a_type = VKI_AT_IGNORE; break; } } *auxv = *orig_auxv; - vg_assert(auxv->a_type == AT_NULL); + vg_assert(auxv->a_type == VKI_AT_NULL); vg_assert((strtab-stringbase) == stringsize); diff --git a/include/vki/vki-freebsd.h b/include/vki/vki-freebsd.h index c7481f31c7..7f32c9cf86 100644 --- a/include/vki/vki-freebsd.h +++ b/include/vki/vki-freebsd.h @@ -2479,7 +2479,48 @@ struct vki_ps_strings { //---------------------------------------------------------------------- #define VKI_AT_NULL 0 +#define VKI_AT_IGNORE 1 +#define VKI_AT_EXECFD 2 +#define VKI_AT_PHDR 3 +#define VKI_AT_PHENT 4 +#define VKI_AT_PHNUM 5 +#define VKI_AT_PAGESZ 6 +#define VKI_AT_BASE 7 +#define VKI_AT_FLAGS 8 +#define VKI_AT_ENTRY 9 +#define VKI_AT_NOTELF 10 +#define VKI_AT_UID 11 +#define VKI_AT_EUID 12 +#define VKI_AT_GID 13 +#define VKI_AT_EGID 14 +#define VKI_AT_EXECPATH 15 +#define VKI_AT_CANARY 16 +#define VKI_AT_CANARYLEN 17 +#define VKI_AT_OSRELDATE 18 +#define VKI_AT_NCPUS 19 +#define VKI_AT_PAGESIZES 20 +#define VKI_AT_PAGESIZESLEN 21 +#define VKI_AT_TIMEKEEP 22 +#define VKI_AT_STACKPROT 23 +#define VKI_AT_EHDRFLAGS 24 +#define VKI_AT_HWCAP 25 +#define VKI_AT_HWCAP2 26 +/* added in FreeBSD 13 */ +#define VKI_AT_BSDFLAGS 27 +#define VKI_AT_ARGC 28 +#define VKI_AT_ARGV 29 +#define VKI_AT_ENVC 30 +#define VKI_AT_ENVV 31 #define VKI_AT_PS_STRINGS 32 +/* added in FreeBSD 13.1 */ +#define VKI_AT_FXRNG 33 +#define VKI_AT_KPRELOAD 34 +/* added in FreeBSD 14 */ +#define VKI_AT_USRSTACKBASE 35 +#define VKI_T_USRSTACKLIM 36 + +/* AT_COUNT depends on the FreeBSD version, not currently used */ + #define VKI_NT_FREEBSD_ABI_TAG 1 #define VKI_NT_FREEBSD_FEATURE_CTL 4 |
|
From: Feiyang C. <chr...@gm...> - 2022-10-25 07:32:09
|
Hi, The series is now rebased on 3.20.0. Could you review this series? https://bugs.kde.org/show_bug.cgi?id=457504 Thanks, Feiyang |
|
From: Mark W. <ma...@kl...> - 2022-10-24 19:47:10
|
We are pleased to announce a new release of Valgrind, version 3.20.0, available from https://valgrind.org/downloads/current.html. See the release notes below for details of changes. Our thanks to all those who contribute to Valgrind's development. This release represents a great deal of time, energy and effort on the part of many people. Happy and productive debugging and profiling, -- The Valgrind Developers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and AMD64/FreeBSD. There is also preliminary support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * ==================== CORE CHANGES =================== * The option "--vgdb-stop-at=event1,event2,..." accepts the new value abexit. This indicates to invoke gdbserver when your program exits abnormally (i.e. with a non zero exit code). * Fix Rust v0 name demangling. * The Linux rseq syscall is now implemented as (silently) returning ENOSYS. * Add FreeBSD syscall wrappers for __specialfd and __realpathat. * Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with HardenedBSD * The option --enable-debuginfod=<no|yes> [default: yes] has been added on Linux. * More DWARF5 support as generated by clang14. * ==================== FIXED BUGS ==================== The following bugs have been fixed or resolved. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. 131186 writev reports error in (vector[...]) 434764 iconv_open causes ld.so v2.28+ to use optimised strncmp 446754 Improve error codes from alloc functions under memcheck 452274 memcheck crashes with Assertion 'sci->status.what == SsIdle' failed 452779 Valgrind fails to build on FreeBSD 13.0 with llvm-devel (15.0.0) 453055 shared_timed_mutex drd test fails with "Lock shared failed" message 453602 Missing command line option to enable/disable debuginfod 452802 Handle lld 9+ split RW PT_LOAD segments correctly 454040 s390x: False-positive memcheck:cond in memmem on arch13 systems 456171 [PATCH] FreeBSD: Don't record address errors when accessing the 'kern.ps_strings' sysctl struct n-i-bz Implement vgdb invoker on FreeBSD 458845 PowerPC: The L field for the dcbf and sync instruction should be 3 bits in ISA 3.1. 458915 Remove register cache to fix 458915 gdbserver causes wrong syscall return 459031 Documentation on --error-exitcode incomplete 459477 XERROR messages lacks ending '\n' in vgdb 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.20.0.RC1: 20 Oct 2022) |
|
From: Mark W. <ma...@so...> - 2022-10-24 12:13:16
|
The signed tag 'VALGRIND_3_20_0' was created pointing to:
5147d671e4... -> 3.20.0 final
Tagger: Mark Wielaard <ma...@kl...>
Date: Mon Oct 24 14:12:22 2022 +0200
valgrind 3.20.0 release
|
|
From: Mark W. <ma...@so...> - 2022-10-24 12:00:49
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=5147d671e4cb053ccc5d015cf1322692cc31f20a commit 5147d671e4cb053ccc5d015cf1322692cc31f20a Author: Mark Wielaard <ma...@kl...> Date: Mon Oct 24 13:59:17 2022 +0200 -> 3.20.0 final Diff: --- NEWS | 8 +++++--- configure.ac | 4 ++-- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index c40a0fc70c..029161cc67 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,4 @@ -Release 3.20.0 (22 Oct 2022) +Release 3.20.0 (24 Oct 2022) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, @@ -16,8 +16,10 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. * Fix Rust v0 name demangling. * The Linux rseq syscall is now implemented as (silently) returning ENOSYS. * Add FreeBSD syscall wrappers for __specialfd and __realpathat. -* Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with HardenedBSD -* The option --enable-debuginfod=<no|yes> [default: yes] has been added on Linux. +* Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with + HardenedBSD +* The option --enable-debuginfod=<no|yes> [default: yes] has been added on + Linux. * More DWARF5 support as generated by clang14. * ==================== FIXED BUGS ==================== diff --git a/configure.ac b/configure.ac index 196dc4c573..4a3f3db22d 100755 --- a/configure.ac +++ b/configure.ac @@ -17,8 +17,8 @@ m4_define([v_major_ver], [3]) m4_define([v_minor_ver], [20]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], [RC1]) -m4_define([v_rel_date], ["20 Oct 2022"]) +m4_define([v_suffix_ver], []) +m4_define([v_rel_date], ["24 Oct 2022"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], |
|
From: Philippe W. <phi...@sk...> - 2022-10-23 14:19:05
|
On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote: > Hi Philippe, > > On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote: > > I have started running valgrind on valgrind (outer/inner setup). > > Results should be available tomorrow evening or so ... > > For the first few tests, seems ok. > > > > Just one strange thing: > > The outer valgrind crashes on the below test (while the native run of this test is ok). > > (this is on gcc farm gcc186). > > > > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, > > but would not be ok when the same valgrind runs as an outer. > > In any case, this is not blocking. > > > > More complete results will follow ... > > Thanks. I have no theory for the outer valgrind crash. But it doesn't > seem blocking indeed. I am also still running some tests. Please let > me know of further results. And do the actual release on Monday > (unless some regression blocker turns up). > > Cheers, > > Mark > For the crash of the outer valgrind: there is in fact some debug info really missing on gcc186 (also for the inner) for the 32 bits version. I have looked at the results of this outer/inner setup and found nothing that seems problematic. Note that analysis the outer logs is always painful, as the outer reports as "bugs" the fact the inner uses e.g. some invalid memory because the guest program run by the inner is designed to test the usage of such invalid memory. Thanks Philippe |
|
From: Paul F. <pj...@wa...> - 2022-10-23 13:36:58
|
On 10/20/22 02:10 PM, Paul Floyd wrote: > > > On 10/20/22 01:52 AM, Mark Wielaard wrote: >> Greetings. >> >> A first release candidate for 3.20.0 is available at >> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 >> (md5 = 981b9276536843090700c1268549186e) >> >> Please give it a try on platforms that are important for you. If no >> serious issues are reported, the 3.20.0 final release will happen on >> 22 October. > > Not quite in the "important platform" category > > Solaris 11.3, everything builds but there are problems with DRD and > Helgrind > > Around the time of 3.19 I was getting > > == 791 tests, 18 stderr failures, 3 stdout failures, 1 stderrB > failure, 0 stdoutB failures, 0 post failures == > Git bisect says Bisecting: 0 revisions left to test after this (roughly 0 steps) [7844752299b5472b21fc4df765d4cffdf92c6c3d] Bug 452802 Handle lld 9+ split RW PT_LOAD segments correctly I just pushed a change that fixes this and should only affect Solaris. A+ Paul |
|
From: Paul F. <pa...@so...> - 2022-10-23 13:29:57
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=328ece846310e9c9ffbe3ae1b8f2678b1bcbd353 commit 328ece846310e9c9ffbe3ae1b8f2678b1bcbd353 Author: Paul Floyd <pj...@wa...> Date: Sun Oct 23 15:16:51 2022 +0200 Fix DRD and Helgrind on Solaris. It seems as though Solaris RW sections can also have the execute flag set. Checking for RW and !X was causing the debuginfo reading to fail. That meant that the helgrind and drd preload shared libraries weren't processed, and also the rtld bind function pointers not setup. Without the rtld bind function an assert fires and Helgrind and DRD abort. Diff: --- coregrind/m_debuginfo/readelf.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c index 6cf08f666f..56e7d4b6f0 100644 --- a/coregrind/m_debuginfo/readelf.c +++ b/coregrind/m_debuginfo/readelf.c @@ -3682,6 +3682,11 @@ Bool ML_(check_elf_and_get_rw_loads) ( Int fd, const HChar* filename, Int * rw_l #else flag_x = 0; #endif + +#if defined(VGO_solaris) + flag_x = 0; +#endif + vg_assert(ehdr_mioff == 0); // ensured by its initialisation ok = ML_(img_valid)(mimg, ehdr_mioff, sizeof(ehdr_m)); vg_assert(ok); // ML_(is_elf_object_file) should ensure this |
|
From: Mark W. <ma...@kl...> - 2022-10-22 22:11:41
|
Hi Philippe, On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote: > I have started running valgrind on valgrind (outer/inner setup). > Results should be available tomorrow evening or so ... > For the first few tests, seems ok. > > Just one strange thing: > The outer valgrind crashes on the below test (while the native run of this test is ok). > (this is on gcc farm gcc186). > > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, > but would not be ok when the same valgrind runs as an outer. > In any case, this is not blocking. > > More complete results will follow ... Thanks. I have no theory for the outer valgrind crash. But it doesn't seem blocking indeed. I am also still running some tests. Please let me know of further results. And do the actual release on Monday (unless some regression blocker turns up). Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2022-10-22 15:36:12
|
Hi,
On Thu, Oct 20, 2022 at 01:25:44PM -0700, Carl Love wrote:
> The only issue noted, as discussed on #valgrind-dev channel, is the
> addition of four post errors for the 3.20RC tree on all of the Power
> platforms. Specifically:
>
> cachegrind/tests/ann1 (post)
> cachegrind/tests/ann2 (post)
> callgrind/tests/ann1 (post)
> callgrind/tests/ann2 (post)
>
> The output from cachegrind/tests/ann1.post.diff is:
>
> --- ann1.post.exp 2021-01-21 09:09:33.000000000 -0600
> +++ ann1.post.out 2022-10-20 14:07:33.272141328 -0500
> @@ -33,6 +33,13 @@
> --------------------------------------------------------------------
> -----------
> -
> -- Auto-annotated source: a.c
> --------------------------------------------------------------------
> -----------
> -
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
> WARNING @@
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@ Source file 'a.c' is more recent than input file 'cgout-test'.
> +@ Annotations may not be correct.
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +
> Ir I1mr ILmr
>
> 2 0 0 int main(void) {
>
> As discussed on the #valgrind-dev channel, this appears to be a
> timestamp issue. Doing a touch * in directory cachegrind/tests seems
> to fix all four post errors.
>
> No other issues were noted. I would vote to do the touch * command and
> go ahead with the release.
I added the touch to the testcases as attached. That makes sure the
cgout-test file is always newer.
Cheers,
Mark
|
|
From: Mark W. <ma...@so...> - 2022-10-22 15:32:49
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=206dbcfed93f22370e03a03dd07f14ab675e24a8 commit 206dbcfed93f22370e03a03dd07f14ab675e24a8 Author: Mark Wielaard <ma...@kl...> Date: Sat Oct 22 17:29:00 2022 +0200 {callgrind,callgrind}/tests/ann{1,2}.vgtest touch cgout-test Both a.c and cgout-test are checked into the repository and used in testcases. Make sure cgout-test is newer than a.c before running the post script to prevent warnings liks: @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ Source file 'a.c' is more recent than input file ../../cachegrind/tests/cgout-test'. @ Annotations may not be correct. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Diff: --- cachegrind/tests/ann1.vgtest | 2 +- cachegrind/tests/ann2.vgtest | 2 +- callgrind/tests/ann1.vgtest | 2 +- callgrind/tests/ann2.vgtest | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/cachegrind/tests/ann1.vgtest b/cachegrind/tests/ann1.vgtest index 676fe31996..e3e574276a 100644 --- a/cachegrind/tests/ann1.vgtest +++ b/cachegrind/tests/ann1.vgtest @@ -2,5 +2,5 @@ # the post-processing of the cgout-test file. prog: ../../tests/true vgopts: --cachegrind-out-file=cachegrind.out -post: perl ../../cachegrind/cg_annotate --show=Ir,I1mr,ILmr --show-percs=no cgout-test +post: touch cgout-test && perl ../../cachegrind/cg_annotate --show=Ir,I1mr,ILmr --show-percs=no cgout-test cleanup: rm cachegrind.out diff --git a/cachegrind/tests/ann2.vgtest b/cachegrind/tests/ann2.vgtest index 5acc68b8d5..14ccd24dbe 100644 --- a/cachegrind/tests/ann2.vgtest +++ b/cachegrind/tests/ann2.vgtest @@ -2,5 +2,5 @@ # the post-processing of the cgout-test file. prog: ../../tests/true vgopts: --cachegrind-out-file=cachegrind.out -post: perl ../../cachegrind/cg_annotate --sort=Dr --show=Dw,Dr,Ir --auto=yes cgout-test +post: touch cgout-test && perl ../../cachegrind/cg_annotate --sort=Dr --show=Dw,Dr,Ir --auto=yes cgout-test cleanup: rm cachegrind.out diff --git a/callgrind/tests/ann1.vgtest b/callgrind/tests/ann1.vgtest index 4ad9ae3903..3c53e1f55e 100644 --- a/callgrind/tests/ann1.vgtest +++ b/callgrind/tests/ann1.vgtest @@ -2,5 +2,5 @@ # the post-processing of the cgout-test file. prog: ../../tests/true vgopts: --callgrind-out-file=callgrind.out -post: perl ../../callgrind/callgrind_annotate --show=Ir,I1mr,ILmr --show-percs=no --include=../../cachegrind/tests ../../cachegrind/tests/cgout-test +post: touch ../../cachegrind/tests/cgout-test && perl ../../callgrind/callgrind_annotate --show=Ir,I1mr,ILmr --show-percs=no --include=../../cachegrind/tests ../../cachegrind/tests/cgout-test cleanup: rm callgrind.out diff --git a/callgrind/tests/ann2.vgtest b/callgrind/tests/ann2.vgtest index 30e177907f..9b7dffa0f0 100644 --- a/callgrind/tests/ann2.vgtest +++ b/callgrind/tests/ann2.vgtest @@ -2,5 +2,5 @@ # the post-processing of the cgout-test file. prog: ../../tests/true vgopts: --callgrind-out-file=callgrind.out -post: perl ../../callgrind/callgrind_annotate --sort=Dr --show=Dw,Dr,Ir --auto=yes --include=../../cachegrind/tests ../../cachegrind/tests/cgout-test +post: touch ../../cachegrind/tests/cgout-test && perl ../../callgrind/callgrind_annotate --sort=Dr --show=Dw,Dr,Ir --auto=yes --include=../../cachegrind/tests ../../cachegrind/tests/cgout-test cleanup: rm callgrind.out |
|
From: Philippe W. <phi...@sk...> - 2022-10-22 12:58:48
|
I have started running valgrind on valgrind (outer/inner setup). Results should be available tomorrow evening or so ... For the first few tests, seems ok. Just one strange thing: The outer valgrind crashes on the below test (while the native run of this test is ok). (this is on gcc farm gcc186). Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, but would not be ok when the same valgrind runs as an outer. In any case, this is not blocking. More complete results will follow ... Philippe cachegrind/tests/x86/fpu-28-108.outer.log:10:valgrind: Fatal error at startup: a function redirection cachegrind/tests/x86/fpu-28-108.outer.log:11:valgrind: which is mandatory for this platform-tool combination cachegrind/tests/x86/fpu-28-108.outer.log:12:valgrind: cannot be set up. Details of the redirection are: cachegrind/tests/x86/fpu-28-108.outer.log:13:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:14:valgrind: A must-be-redirected function cachegrind/tests/x86/fpu-28-108.outer.log:15:valgrind: whose name matches the pattern: strlen cachegrind/tests/x86/fpu-28-108.outer.log:16:valgrind: in an object with soname matching: ld-linux.so.2 cachegrind/tests/x86/fpu-28-108.outer.log:17:valgrind: was not found whilst processing cachegrind/tests/x86/fpu-28-108.outer.log:18:valgrind: symbols from the object with soname: ld-linux.so.2 cachegrind/tests/x86/fpu-28-108.outer.log:19:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:20:valgrind: Possible fixes: (1, short term): install glibc's debuginfo cachegrind/tests/x86/fpu-28-108.outer.log:21:valgrind: package on this machine. (2, longer term): ask the packagers cachegrind/tests/x86/fpu-28-108.outer.log:22:valgrind: for your Linux distribution to please in future ship a non- cachegrind/tests/x86/fpu-28-108.outer.log:23:valgrind: stripped ld.so (or whatever the dynamic linker .so is called) cachegrind/tests/x86/fpu-28-108.outer.log:24:valgrind: that exports the above-named function using the standard cachegrind/tests/x86/fpu-28-108.outer.log:25:valgrind: calling conventions for this platform. The package you need cachegrind/tests/x86/fpu-28-108.outer.log:26:valgrind: to install for fix (1) is called cachegrind/tests/x86/fpu-28-108.outer.log:27:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:28:valgrind: On Debian, Ubuntu: libc6-dbg cachegrind/tests/x86/fpu-28-108.outer.log:29:valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo cachegrind/tests/x86/fpu-28-108.outer.log:30:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:31:valgrind: Note that if you are debugging a 32 bit process on a cachegrind/tests/x86/fpu-28-108.outer.log:32:valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo cachegrind/tests/x86/fpu-28-108.outer.log:33:valgrind: package (e.g. libc6-dbg:i386). cachegrind/tests/x86/fpu-28-108.outer.log:34:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:35:valgrind: Cannot continue -- exiting now. Sorry. On Thu, 2022-10-20 at 01:52 +0200, Mark Wielaard wrote: > Greetings. > > A first release candidate for 3.20.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 > (md5 = 981b9276536843090700c1268549186e) > > Please give it a try on platforms that are important for you. If no > serious issues are reported, the 3.20.0 final release will happen on > 22 October. > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Paul F. <pa...@so...> - 2022-10-20 21:15:22
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=0ea3746e978420963760051e6f821f9b5c3d872d commit 0ea3746e978420963760051e6f821f9b5c3d872d Author: Paul Floyd <pj...@wa...> Date: Thu Oct 20 23:11:42 2022 +0200 Fix build on macOS A while back when I added support for split RW PT_LOAD sections one instance in the macho code didn't get updated. Also update the comment that refers to the old struct member that got renamed. Diff: --- coregrind/m_debuginfo/priv_storage.h | 6 +++--- coregrind/m_debuginfo/readmacho.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/coregrind/m_debuginfo/priv_storage.h b/coregrind/m_debuginfo/priv_storage.h index f44ab43ffe..a4b90d36b3 100644 --- a/coregrind/m_debuginfo/priv_storage.h +++ b/coregrind/m_debuginfo/priv_storage.h @@ -541,9 +541,9 @@ ML_(cmp_for_DiAddrRange_range) ( const void* keyV, const void* elemV ); essentially an ultra-trivial finite state machine which, when it reaches an accept state, signals that we should now read debug info from the object into the associated struct _DebugInfo. The accept - state is arrived at when have_rx_map and have_rw_map both become - true. The initial state is one in which we have no observations, - so have_rx_map and have_rw_map are both false. + state is arrived at when have_rx_map is true and rw_map_count + is 1 or 2. The initial state is one in which we have no observations, + so have_rx_map is false and rw_map_count is 0. This all started as a rather ad-hoc solution, but was further expanded to handle weird object layouts, e.g. more than one rw diff --git a/coregrind/m_debuginfo/readmacho.c b/coregrind/m_debuginfo/readmacho.c index 61a3fe9f5a..33cc037b57 100644 --- a/coregrind/m_debuginfo/readmacho.c +++ b/coregrind/m_debuginfo/readmacho.c @@ -714,7 +714,7 @@ Bool ML_(read_macho_debug_info)( struct _DebugInfo* di ) /* This should be ensured by our caller (that we're in the accept state). */ vg_assert(di->fsm.have_rx_map); - vg_assert(di->fsm.have_rw_map); + vg_assert(di->fsm.rw_map_count); for (i = 0; i < VG_(sizeXA)(di->fsm.maps); i++) { const DebugInfoMapping* map = VG_(indexXA)(di->fsm.maps, i); |
|
From: Carl L. <ce...@us...> - 2022-10-20 20:26:14
|
Mark: On Thu, 2022-10-20 at 01:52 +0200, Mark Wielaard wrote: > Greetings. > > A first release candidate for 3.20.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 > (md5 = 981b9276536843090700c1268549186e) > > Please give it a try on platforms that are important for you. If no > serious issues are reported, the 3.20.0 final release will happen on > 22 October. The RC was run on Power 7, Power 8BE, Power 8LE, Power 9 and Power 10. The number of failures and stdout failures for the 3.20RC was the same or lower than what was seen on 3.19 for each of the platforms. The only issue noted, as discussed on #valgrind-dev channel, is the addition of four post errors for the 3.20RC tree on all of the Power platforms. Specifically: cachegrind/tests/ann1 (post) cachegrind/tests/ann2 (post) callgrind/tests/ann1 (post) callgrind/tests/ann2 (post) The output from cachegrind/tests/ann1.post.diff is: --- ann1.post.exp 2021-01-21 09:09:33.000000000 -0600 +++ ann1.post.out 2022-10-20 14:07:33.272141328 -0500 @@ -33,6 +33,13 @@ -------------------------------------------------------------------- ----------- - -- Auto-annotated source: a.c -------------------------------------------------------------------- ----------- - +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@ +@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@ +@ Source file 'a.c' is more recent than input file 'cgout-test'. +@ Annotations may not be correct. +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@ + Ir I1mr ILmr 2 0 0 int main(void) { As discussed on the #valgrind-dev channel, this appears to be a timestamp issue. Doing a touch * in directory cachegrind/tests seems to fix all four post errors. No other issues were noted. I would vote to do the touch * command and go ahead with the release. Carl |
|
From: Paul F. <pj...@wa...> - 2022-10-20 12:10:45
|
On 10/20/22 01:52 AM, Mark Wielaard wrote: > Greetings. > > A first release candidate for 3.20.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 > (md5 = 981b9276536843090700c1268549186e) > > Please give it a try on platforms that are important for you. If no > serious issues are reported, the 3.20.0 final release will happen on > 22 October. Not quite in the "important platform" category Solaris 11.3, everything builds but there are problems with DRD and Helgrind Around the time of 3.19 I was getting == 791 tests, 18 stderr failures, 3 stdout failures, 1 stderrB failure, 0 stdoutB failures, 0 post failures == 3.20 RC1 == 792 tests, 197 stderr failures, 19 stdout failures, 1 stderrB failure, 1 stdoutB failure, 5 post failures == I haven't analyzed but DRD testcases are giving this error +Bind guard functions for the runtime linker (ld.so.1) were not intercepted. +This means the interface between libc and runtime linker changed and DRD +needs to be ported properly. Giving up. + +Process terminating with default action of signal 6 (SIGABRT) + at 0x........: vgDrd_init (in /export/home/paulf/vg_3_12/valgrind-3.20.0.RC1/drd/vgpreload_drd-amd64-solaris.so) + by 0x........: ??? (in /export/home/paulf/vg_3_12/valgrind-3.20.0.RC1/drd/vgpreload_drd-amd64-solaris.so) + by 0x........: _init (in /export/home/paulf/vg_3_12/valgrind-3.20.0.RC1/drd/vgpreload_drd-amd64-solaris.so) + by 0x........: ??? (in /lib/amd64/ld.so.1) + by 0x........: ??? (in /lib/amd64/ld.so.1) + by 0x........: ??? (in /lib/amd64/ld.so.1) + by 0x........: ??? (in /lib/amd64/ld.so.1) + by 0x........: ??? My Solaris system has barely changed (I rarely even boot it these days). Not blocking for me. A+ Paul |
|
From: Mark W. <ma...@kl...> - 2022-10-19 23:52:56
|
Greetings. A first release candidate for 3.20.0 is available at https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 (md5 = 981b9276536843090700c1268549186e) Please give it a try on platforms that are important for you. If no serious issues are reported, the 3.20.0 final release will happen on 22 October. |
|
From: Mark W. <ma...@so...> - 2022-10-19 23:40:59
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=b112a9b37a85bdb3d1861530285162d511f78035 commit b112a9b37a85bdb3d1861530285162d511f78035 Author: Mark Wielaard <ma...@kl...> Date: Thu Oct 20 01:40:12 2022 +0200 Set version to 3.20.0-RC1 and update NEWS Diff: --- NEWS | 17 ++++------------- configure.ac | 4 ++-- 2 files changed, 6 insertions(+), 15 deletions(-) diff --git a/NEWS b/NEWS index a5c0a2d017..c40a0fc70c 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,4 @@ -Release 3.20.0 (?? Oct 2022) +Release 3.20.0 (22 Oct 2022) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux, @@ -17,17 +17,8 @@ AMD64/macOS 10.13 and nanoMIPS/Linux. * The Linux rseq syscall is now implemented as (silently) returning ENOSYS. * Add FreeBSD syscall wrappers for __specialfd and __realpathat. * Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with HardenedBSD - -* ================== PLATFORM CHANGES ================= - -* arm64: - -* s390: - -* ppc64: - -* ==================== TOOL CHANGES =================== - +* The option --enable-debuginfod=<no|yes> [default: yes] has been added on Linux. +* More DWARF5 support as generated by clang14. * ==================== FIXED BUGS ==================== @@ -59,7 +50,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.20.0.RC1: ?? Oct 2022) +(3.20.0.RC1: 20 Oct 2022) Release 3.19.0 (11 Apr 2022) diff --git a/configure.ac b/configure.ac index 369daa173a..196dc4c573 100755 --- a/configure.ac +++ b/configure.ac @@ -17,8 +17,8 @@ m4_define([v_major_ver], [3]) m4_define([v_minor_ver], [20]) m4_define([v_micro_ver], [0]) -m4_define([v_suffix_ver], [GIT]) -m4_define([v_rel_date], ["?? Oct 2022"]) +m4_define([v_suffix_ver], [RC1]) +m4_define([v_rel_date], ["20 Oct 2022"]) m4_define([v_version], m4_if(v_suffix_ver, [], [v_major_ver.v_minor_ver.v_micro_ver], |
|
From: Nicholas N. <n.n...@gm...> - 2022-10-19 23:07:01
|
John: I suggest you temper your tone. Mahin is a newcomer who has asked a question in good faith, and doesn't deserve an aggressive reply. Mahin: As the error message says: "Your program has a bug and erroneously jumped to a non-codelocation. If you are running Memcheck and you just saw a warning about a bad jump, it's probably your program's fault." I suggest addressing all the errors reported by Valgrind prior to the "Unrecognised instruction" message. I also suggest checking the return value of `fopen` calls for errors. As for profiling source code, Cachegrind and Callgrind are two tools that come with Valgrind that are good for this. You can read about them in the user manual. `perf` is also a good profiling tool, as John mentioned. Finally, there is a valgrind-users email list that is more appropriate for this kind of question. This list (valgrind-developers) is more about the development of Valgrind itself, rather than its use. Nick On Thu, 20 Oct 2022 at 00:49, John Reiser <jr...@bi...> wrote: > On 10/19/22 01:40, Mahin Pandya wrote: > > I am getting below error while running Valgrind, not sure if this is bug > in Valgrind, application is build using Wine lib. > > > > Can someone check this? > > > > --------------------- > > > > … > > > > ==2214549== Invalid write of size 8 > > > > ==2214549== at 0x46C0040: setup_raise_exception (signal_x86_64.c:2158) > > > > ==2214549== by 0x46C0653: segv_handler (signal_x86_64.c:2626) > > > > ==2214549== by 0x407641F: ??? (in /usr/lib/x86_64-linux-gnu/ > libpthread-2.31.so) > > > > ==2214549== Address 0x22fbd0 is in a rw- anonymous segment > [[snip]] > > This query is so defective that we'll just ignore it until you fix it. > > 1. Which version of valgrind? Report the output from "valgrind --version". > Where did you get it? If self-built from source then report the git commit > hash and date. If pre-built from a software distribution, then report > the name and version of the distribution, and the package name and version. > > 2. Which version of Wine lib? Also give the URL for download of the > software > and installation instructions. > > 3. Which execution environment? Report the output from "sed 10q > /proc/cpuinfo" > and the VM booting banner from early lines of "dmesg". It really does > matter > which actual or Virtual Machine. > > 4. Which underlying physical hardware (Intel or AMD)? [Perhaps the same > as #3.] > > > > > Is there option I could use Valgrind for profiling source code? Any > pointers/suggestion are welcome. > > DO NOT start a profiling project using valgrind. Instead, start with > 'perf' > which is vastly more capable, flexible, and fast. > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Mark W. <ma...@so...> - 2022-10-19 22:35:46
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=6a5a689fd901e4abcd2f0fcc64adc14ea3122ad0 commit 6a5a689fd901e4abcd2f0fcc64adc14ea3122ad0 Author: Mark Wielaard <ma...@kl...> Date: Thu Oct 20 00:34:15 2022 +0200 Add none/tests/freebsd/auxv.stderr.exp-freebsd14 to EXTRA_DIST Diff: --- none/tests/freebsd/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/none/tests/freebsd/Makefile.am b/none/tests/freebsd/Makefile.am index f1f8a5628b..030af12d20 100644 --- a/none/tests/freebsd/Makefile.am +++ b/none/tests/freebsd/Makefile.am @@ -8,6 +8,7 @@ EXTRA_DIST = \ auxv.stderr.exp-32on64 \ auxv.stderr.exp-freebsd13 \ auxv.stderr.exp-freebsd131 \ + auxv.stderr.exp-freebsd14 \ cp.vgtest \ cp.stderr.exp \ osrel.vgtest \ |
|
From: John R. <jr...@bi...> - 2022-10-19 13:48:30
|
On 10/19/22 01:40, Mahin Pandya wrote: > I am getting below error while running Valgrind, not sure if this is bug in Valgrind, application is build using Wine lib. > > Can someone check this? > > --------------------- > > … > > ==2214549== Invalid write of size 8 > > ==2214549== at 0x46C0040: setup_raise_exception (signal_x86_64.c:2158) > > ==2214549== by 0x46C0653: segv_handler (signal_x86_64.c:2626) > > ==2214549== by 0x407641F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.31.so) > > ==2214549== Address 0x22fbd0 is in a rw- anonymous segment [[snip]] This query is so defective that we'll just ignore it until you fix it. 1. Which version of valgrind? Report the output from "valgrind --version". Where did you get it? If self-built from source then report the git commit hash and date. If pre-built from a software distribution, then report the name and version of the distribution, and the package name and version. 2. Which version of Wine lib? Also give the URL for download of the software and installation instructions. 3. Which execution environment? Report the output from "sed 10q /proc/cpuinfo" and the VM booting banner from early lines of "dmesg". It really does matter which actual or Virtual Machine. 4. Which underlying physical hardware (Intel or AMD)? [Perhaps the same as #3.] > > Is there option I could use Valgrind for profiling source code? Any pointers/suggestion are welcome. DO NOT start a profiling project using valgrind. Instead, start with 'perf' which is vastly more capable, flexible, and fast. |
|
From: Mahin P. <mah...@ac...> - 2022-10-19 08:56:18
|
Hi All,
I am getting below error while running Valgrind, not sure if this is bug in Valgrind, application is build using Wine lib.
Can someone check this?
---------------------
…
==2214549== Invalid write of size 8
==2214549== at 0x46C0040: setup_raise_exception (signal_x86_64.c:2158)
==2214549== by 0x46C0653: segv_handler (signal_x86_64.c:2626)
==2214549== by 0x407641F: ??? (in /usr/lib/x86_64-linux-gnu/libpthread-2.31.so)
==2214549== Address 0x22fbd0 is in a rw- anonymous segment
…
…
==2214549== valgrind: Unrecognised instruction at address 0x46bc3d9.
==2214549== at 0x46BC3D9: __wine_syscall_dispatcher (in /usr/local/lib/wine/x86_64-unix/ntdll.so)
==2214549== by 0x170055EEF: LdrResolveDelayLoadedAPI (loader.c:3515)
==2214549== Your program just tried to execute an instruction that Valgrind
==2214549== did not recognise. There are two possible reasons for this.
==2214549== 1. Your program has a bug and erroneously jumped to a non-code
==2214549== location. If you are running Memcheck and you just saw a
==2214549== warning about a bad jump, it's probably your program's fault.
==2214549== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2214549== i.e. it's Valgrind's fault. If you think this is the case or
==2214549== you are not sure, please let us know and we'll try to fix it.
==2214549== Either way, Valgrind will now raise a SIGILL signal which will
==2214549== probably kill your program.
0508:err:seh:segv_handler Got unexpected trap 0
…
--------------------------------
Source code :
> cat a.c
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
int main (int argc, char *argv[])
{
FILE *fin;
FILE *fout;
char wc;
fin=fopen("fin","r");
fout=fopen("out.txt","w,ccs=UTF-8");
while((wc=fgetc(fin))!=EOF){
fputc(wc,fout);
printf("%c", wc );
}
fclose(fin);
fclose(fout);
printf("\nFile has been created...%d\n", getpid());
sum(1);
return 0;
}
> cat c.c
void sum(int i)
{
return ;
}
void sum1(int i)
{
return ;
}
winegcc -g -o c.o -c c.c
winegcc -g -o a.out a.c c.o
valgrind --trace-children=yes wine64 a.out.so > temp.out 2>&1
Is there option I could use Valgrind for profiling source code? Any pointers/suggestion are welcome.
regards,
Mahin
|
|
From: Paul F. <pj...@wa...> - 2022-10-19 05:21:12
|
On 10/18/22 22:03, Nicholas Nethercote wrote: > It would be great to have a new release out. Currently you have to use a > trunk build of Valgrind with Rust code because of Dwarf 5 features that > Rust uses. > > Nick Hi I'm also ready to go. A+ Paul |