You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
|
From: Paul F. <pa...@so...> - 2021-11-29 21:49:46
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=521e4690091e36ac8e1fbf388f8e30615a50f0d0 commit 521e4690091e36ac8e1fbf388f8e30615a50f0d0 Author: Paul Floyd <pj...@wa...> Date: Mon Nov 29 22:44:17 2021 +0100 Bug 446251 TARGET_SIGNAL_THR added to enum target_signal gdb considers FreeBSD SIGTHR to be the evuivalent if SIGLWP not a signal in its own right. Remove the extra enum entry (which fixes errors in converting signals from number to string) and map TARGET_SIGNAL_LWP to SIGTHR. Diff: --- coregrind/m_gdbserver/gdb/signals.h | 5 ++--- coregrind/m_gdbserver/signals.c | 18 +++++++++--------- 2 files changed, 11 insertions(+), 12 deletions(-) diff --git a/coregrind/m_gdbserver/gdb/signals.h b/coregrind/m_gdbserver/gdb/signals.h index 4857475fa3..81f373ae78 100644 --- a/coregrind/m_gdbserver/gdb/signals.h +++ b/coregrind/m_gdbserver/gdb/signals.h @@ -137,9 +137,6 @@ enum target_signal /* Used internally by Solaris threads. See signal(5) on Solaris. */ TARGET_SIGNAL_CANCEL = 76, - /* Similar to the above, but for FreeBSD */ - TARGET_SIGNAL_THR = 77, - /* Yes, this pains me, too. But LynxOS didn't have SIG32, and now GNU/Linux does, and we can't disturb the numbering, since it's part of the remote protocol. Note that in some GDB's @@ -235,6 +232,8 @@ enum target_signal /* If you are adding a new signal, add it just above this comment. */ + + /* Last and unused enum value, for sizing arrays, etc. */ TARGET_SIGNAL_LAST }; diff --git a/coregrind/m_gdbserver/signals.c b/coregrind/m_gdbserver/signals.c index 9aee90fcba..fc4cdf2178 100644 --- a/coregrind/m_gdbserver/signals.c +++ b/coregrind/m_gdbserver/signals.c @@ -78,7 +78,7 @@ static struct { {"SIGWIND", "SIGWIND"}, {"SIGPHONE", "SIGPHONE"}, {"SIGWAITING", "Process's LWPs are blocked"}, - {"SIGLWP", "Signal LWP"}, + {"SIGLWP", "Signal LWP"}, /* FreeBSD SIGTHR */ {"SIGDANGER", "Swap space dangerously low"}, {"SIGGRANT", "Monitor mode granted"}, {"SIGRETRACT", "Need to relinquish monitor mode"}, @@ -404,10 +404,6 @@ enum target_signal target_signal_from_host (int hostsig) if (hostsig == VKI_SIGCANCEL) return TARGET_SIGNAL_CANCEL; #endif -#if defined(VKI_SIGTHR) - if (hostsig == VKI_SIGTHR) - return TARGET_SIGNAL_THR; -#endif #if defined (VKI_SIGLWP) if (hostsig == VKI_SIGLWP) return TARGET_SIGNAL_LWP; @@ -475,6 +471,10 @@ enum target_signal target_signal_from_host (int hostsig) if (hostsig == VKI_SIGLIBRT) return TARGET_SIGNAL_LIBRT; #endif +#if defined(VKI_SIGTHR) + if (hostsig == VKI_SIGTHR) + return TARGET_SIGNAL_LWP; +#endif #if defined (VKI_SIGRTMIN) if (hostsig >= VKI_SIGRTMIN && hostsig < VKI_SIGRTMAX) { @@ -661,10 +661,6 @@ int do_target_signal_to_host (enum target_signal oursig, case TARGET_SIGNAL_CANCEL: return VKI_SIGCANCEL; #endif -#if defined (VKI_SIGTHR) - case TARGET_SIGNAL_THR: - return VKI_SIGTHR; -#endif #if defined (VKI_SIGLWP) case TARGET_SIGNAL_LWP: return VKI_SIGLWP; @@ -732,6 +728,10 @@ int do_target_signal_to_host (enum target_signal oursig, case TARGET_SIGNAL_LIBRT: return SIGLIBRT; #endif +#if defined (VKI_SIGTHR) + case TARGET_SIGNAL_LWP: + return VKI_SIGTHR; +#endif default: #if defined (VKI_SIGRTMIN) |
|
From: Paul F. <pa...@so...> - 2021-11-27 22:51:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=f782a688b4c70007139592f17da7a481877dce5f commit f782a688b4c70007139592f17da7a481877dce5f Author: Paul Floyd <pj...@wa...> Date: Sat Nov 27 23:49:34 2021 +0100 Add a FreeBSD helgrind suppression for thread exit This happens when using std::thread. Diff: --- freebsd-helgrind.supp | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/freebsd-helgrind.supp b/freebsd-helgrind.supp index d24ff859bf..8a5018384c 100644 --- a/freebsd-helgrind.supp +++ b/freebsd-helgrind.supp @@ -49,6 +49,20 @@ fun:pthread_exit obj:/lib/libthr.so.3 } +{ + HELGRIND-PTHREAD-EXIT6 + 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 + fun:_Unwind_ForcedUnwind + obj:*/lib*/libthr.so.3 + obj:*/lib*/libthr.so.3 + fun:pthread_exit + obj:*/lib*/libthr.so.3 +} { HELGRIND-PTHREAD-BARRIER2 Helgrind:Race |
|
From: Roger L. <ro...@at...> - 2021-11-26 23:52:49
|
On Fri, 26 Nov 2021 at 12:12, Mark Wielaard <ma...@kl...> wrote: > - Has anybody seen Valkyrie? She has been missing in action. https://github.com/ralight/valkyrie contains a "git svn clone" copy of the valkyrie repository. I've fixed up the qmake settings and a reasonable chunk of the deprecation warnings, so it now compiles and runs on Qt 5. The remaining warnings are mostly around the XML parsing component and look like they would be more than just a few simple line changes. I've spent some time this evening doing this in front of the telly, but it should not be considered as any sort of commitment to do anything more on it... Cheers, Roger |
|
From: Mark W. <ma...@kl...> - 2021-11-26 16:51:53
|
This is in 10 minutes from now: Join the meeting: https://meet.jit.si/ValgrindDevMeeting To join by phone instead, tap this: +1.512.647.1431,,546721826# Looking for a different dial-in number? See meeting dial-in numbers: https://meet.jit.si/static/dialInInfo.html?room=ValgrindDevMeeting If also dialing-in through a room phone, join without connecting to audio: https://meet.jit.si/ValgrindDevMeeting#config.startSilent=true |
|
From: Mark W. <ma...@kl...> - 2021-11-26 12:11:20
|
Hi, On Tue, 2021-11-23 at 11:32 +0100, Julian Seward wrote: > A couple of us thought that it would be nice to have, from time to > time, a > group video call for developers. So that we can talk, discuss the status of > work, problems, who needs help with what, and generally just associate faces > and personalities with names. > > The call is at Fri 26 Nov, 1700 UTC / 1800 CET / 0900 PST. You can join from > your web browser (meaning, it runs within the browser) at > https://meet.jit.si/ValgrindDevMeeting. Here is a proposed "agenda" with topics we could discuss: - Roundtable introductions, who is who - Next year valgrind will be 20! Party whole year! valgrind 1.0 was released on July 28, 2002 - Celebrate at virtual Fosdem? 5 & 6 Feb 2022 (If we get picked for a virtual devroom) - How did the website migration go? - All hackers with git commit access can update it now - Did people even notice? Any import broken links? - Has anybody seen Valkyrie? She has been missing in action. - Release cycle and minor/fixup releases - When should the next one be? - Fedora already carries 18 backports for fixups (some are really minor though, just test cleanups) https://bugzilla.redhat.com/show_bug.cgi?id=2025639 - Any important work/bugs people like to discuss? - AVX512? - debuginfod-find vs SIGCHILD? - s390x vs vsdo restartable syscalls? - Is this a good day/time to have a virtual meetup? (Maybe this is best answered by those not attending...) |
|
From: Paul F. <pj...@wa...> - 2021-11-24 19:26:28
|
On 24/11/2021 00:11, Bart Van Assche wrote: > > Hi Paul, > > Has it been considered to change the compiler flags instead of the > test case source > code? > Hi Bart I was just doing some testing with GCC git head (future GCC 12). For these two I was trying to see a bit what the compiler was doing, and since I already fixed the error (without causing any older compilers to fail) I pushed the changes. Looking forward, there looks like a lot of changes will be required to keep the regression tests clean - I got over 130 failures in total. Removing optimization will certainly be one option, and generally I prefer that over changes that require expected to be updated. I don't have any plans to resolve these failures en masse, though I may chip away at a few as I work on other things. A+ Paul |
|
From: Ambalu, R.
|
Understood, thanik you for the thorough explanation. I'll pass along to the pyarrow maintainers -----Original Message----- From: John Reiser <jr...@bi...> Sent: Tuesday, November 23, 2021 6:09 PM To: val...@li... Subject: Re: [Valgrind-developers] Unrecognised instruction request On 11/23/21 08:46, Ambalu, Robert wrote: > 0x62 0xF1 0xFD 0x8 0x6F 0x44 0x24 0xA 0xC7 0x43 This is vmovdqa64 0xa0(%rsp),%xmm0 which requires CPU feature flag AVX512VL/AVX512F which is not supported by valgrind 3.18.1. In the results of the emulated CPUID instruction, valgrind tells the running application that AVX512 is not supported. It is a bug in pyarrow ( python ) that its initialization routine does not check the cpu feature flags, and switch its later run-time instructions appropriately. Please report this bug to the maintainers of pyarrow. Modern run-time libraries use the STT_GNU_IFUNC feature to choose at run time which instruction set is available and may be used. pyarrow (and/or python3 itself) must upgrade. Gcc supports compile-time feature flags to avoid generating code that uses certain instructions. Run "info gcc" and search for "avx512", paying attention to the flags beginning with "-mavx512", and in particular the "-mno-avx512" variants. Some software administration systems for installing and maintaining software packages can limit the hardware features that packages may assume. You may be able to work-around valgrind's non-support for AVX512 by telling the packaging system to avoid the package variants which require AVX512. _______________________________________________ Valgrind-developers mailing list Val...@li... https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/valgrind-developers__;!!K_TC0FI_KA!4V2IlnDw8tJ7DJLRT5jea4uUWHWCfZRWe2_efWl48nET9r5gND9JGkZHVEKQHVGzdBACBg$ DISCLAIMER: This e-mail message and any attachments are intended solely for the use of the individual or entity to which it is addressed and may contain information that is confidential or legally privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and permanently delete this message and any attachments. |
|
From: Bart V. A. <bva...@ac...> - 2021-11-23 23:11:21
|
On 11/23/21 2:42 PM, Paul Floyd wrote: > https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=49fe0dc74a07ea4c5077867e44127eb68466eded > > commit 49fe0dc74a07ea4c5077867e44127eb68466eded > Author: Paul Floyd <pj...@wa...> > Date: Tue Nov 23 23:37:02 2021 +0100 > > Anticipate testcase problems with GCC 12 > > There will be a lot more to come. > > On amd64 Linux > In faultstatus was seeing the division by zero and emitting a ud2 opcode. > In wrap3 a pair of mutually recursive functions were being inlined. > When forced not to be inlined GCC merged them into a single function. > It cannot see that the client requests have diffeent behaviour. Hi Paul, Has it been considered to change the compiler flags instead of the test case source code? Thanks, Bart. |
|
From: John R. <jr...@bi...> - 2021-11-23 23:08:41
|
On 11/23/21 08:46, Ambalu, Robert wrote: > 0x62 0xF1 0xFD 0x8 0x6F 0x44 0x24 0xA 0xC7 0x43 This is vmovdqa64 0xa0(%rsp),%xmm0 which requires CPU feature flag AVX512VL/AVX512F which is not supported by valgrind 3.18.1. In the results of the emulated CPUID instruction, valgrind tells the running application that AVX512 is not supported. It is a bug in pyarrow ( python ) that its initialization routine does not check the cpu feature flags, and switch its later run-time instructions appropriately. Please report this bug to the maintainers of pyarrow. Modern run-time libraries use the STT_GNU_IFUNC feature to choose at run time which instruction set is available and may be used. pyarrow (and/or python3 itself) must upgrade. Gcc supports compile-time feature flags to avoid generating code that uses certain instructions. Run "info gcc" and search for "avx512", paying attention to the flags beginning with "-mavx512", and in particular the "-mno-avx512" variants. Some software administration systems for installing and maintaining software packages can limit the hardware features that packages may assume. You may be able to work-around valgrind's non-support for AVX512 by telling the packaging system to avoid the package variants which require AVX512. |
|
From: Paul F. <pa...@so...> - 2021-11-23 22:42:20
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=49fe0dc74a07ea4c5077867e44127eb68466eded commit 49fe0dc74a07ea4c5077867e44127eb68466eded Author: Paul Floyd <pj...@wa...> Date: Tue Nov 23 23:37:02 2021 +0100 Anticipate testcase problems with GCC 12 There will be a lot more to come. On amd64 Linux In faultstatus was seeing the division by zero and emitting a ud2 opcode. In wrap3 a pair of mutually recursive functions were being inlined. When forced not to be inlined GCC merged them into a single function. It cannot see that the client requests have diffeent behaviour. Diff: --- memcheck/tests/wrap3.c | 6 ++++-- none/tests/faultstatus.c | 4 +++- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/memcheck/tests/wrap3.c b/memcheck/tests/wrap3.c index 1510d1311f..c6c552d5df 100644 --- a/memcheck/tests/wrap3.c +++ b/memcheck/tests/wrap3.c @@ -5,17 +5,19 @@ /* Check that function wrapping works for a mutually recursive pair. */ -static int fact1 ( int n ); -static int fact2 ( int n ); +int fact1 ( int n ); +int fact2 ( int n ); /* This is needed to stop gcc4 turning 'fact' into a loop */ __attribute__((noinline)) int mul ( int x, int y ) { return x * y; } +__attribute((noinline)) int fact1 ( int n ) { if (n == 0) return 1; else return mul(n, fact2(n-1)); } +__attribute((noinline)) int fact2 ( int n ) { if (n == 0) return 1; else return mul(n, fact1(n-1)); diff --git a/none/tests/faultstatus.c b/none/tests/faultstatus.c index 1b583d9d42..458ea82645 100644 --- a/none/tests/faultstatus.c +++ b/none/tests/faultstatus.c @@ -190,7 +190,9 @@ int main() return 0; } +static volatile s_zero; + static int zero() { - return 0; + return s_zero; } |
|
From: Paul F. <pa...@so...> - 2021-11-23 21:01:50
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=01e05ea81c4886636b44545eb501139b76d5dc7a commit 01e05ea81c4886636b44545eb501139b76d5dc7a Author: Paul Floyd <pj...@wa...> Date: Tue Nov 23 21:58:45 2021 +0100 Disable auxv PAGESIZES workaround on FreeBSD 13 Leaving it in place for 11 (which is now EOL) and 12 - not woth the complexity for them. Improve comment for supporession. Also add a pointer to the illumos source web page for lwp_unlock_mutex in case the syswrap ever needs improving. Diff: --- coregrind/m_initimg/initimg-freebsd.c | 15 +++++++++++++-- coregrind/m_syswrap/syswrap-solaris.c | 2 ++ freebsd.supp | 6 +++++- 3 files changed, 20 insertions(+), 3 deletions(-) diff --git a/coregrind/m_initimg/initimg-freebsd.c b/coregrind/m_initimg/initimg-freebsd.c index d19186a42c..71fb8add17 100644 --- a/coregrind/m_initimg/initimg-freebsd.c +++ b/coregrind/m_initimg/initimg-freebsd.c @@ -578,7 +578,7 @@ Addr setup_client_stack( void* init_sp, /* --- auxv --- */ auxv = (struct auxv *)ptr; *client_auxv = (UInt *)auxv; -#if defined(VGP_x86_freebsd) +#if defined(VGP_x86_freebsd) && (VGO_freebsd <= FREEBSD_13) int* pagesizes = NULL; #endif @@ -610,6 +610,17 @@ Addr setup_client_stack( void* init_sp, * copies out the data for a sysctl sees this discrepancy and * sets an ENOMEM error. So guest execution doesn't even get past * executing the dynamic linker. + * + * This was fixed in the kernel in May 2020, see + * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246215 + * + * That means this workaround is not needed for + * FreeBSD 13 or later, any version + * FreeBSD 12 1201515 and later + * FreeBSD 11 1104501 and later + * + * Because this is rather complicated I've just disabled the hack + * for 13 and later */ for (; orig_auxv->a_type != AT_NULL; auxv++, orig_auxv++) { @@ -649,7 +660,7 @@ Addr setup_client_stack( void* init_sp, // case AT_CANARYLEN: // case AT_EXECPATH: // case AT_CANARY: -#if defined(VGP_x86_freebsd) +#if defined(VGP_x86_freebsd) && (VGO_freebsd <= FREEBSD_13) case AT_PAGESIZESLEN: if (!VG_(is32on64)()) { VG_(debugLog)(2, "initimg", diff --git a/coregrind/m_syswrap/syswrap-solaris.c b/coregrind/m_syswrap/syswrap-solaris.c index d1ce0fd6bb..ea46073427 100644 --- a/coregrind/m_syswrap/syswrap-solaris.c +++ b/coregrind/m_syswrap/syswrap-solaris.c @@ -10639,6 +10639,8 @@ PRE(sys_lwp_mutex_register) PRE(sys_lwp_mutex_unlock) { /* int lwp_mutex_unlock(lwp_mutex_t *lp); */ + /* see https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/syscall/lwp_sobj.c#L3137-L3138 + * (illumos, obviously) */ vki_lwp_mutex_t *lp = (vki_lwp_mutex_t*)ARG1; PRINT("sys_lwp_mutex_unlock ( %#lx )", ARG1); PRE_REG_READ1(int, "lwp_mutex_unlock", lwp_mutex_t *, lp); diff --git a/freebsd.supp b/freebsd.supp index b86b800d80..10d4a10454 100644 --- a/freebsd.supp +++ b/freebsd.supp @@ -1,5 +1,9 @@ # Suppressions for FreeBSD / Memcheck -#This is a workaround for a bug in rtld + +# This is a workaround for a bug in rtld / sysctl hw.pagesizes +# it was fixed in May 2020 in the kernel +# removing it means either waiting for 12-RELEASE EOL +# or some tricky kernel detection in configure.ac { MEMCHECK-RTLD-32ON64 Memcheck:Addr4 |
|
From: Ambalu, R.
|
Dear community, I noticed lately that I'm no longer able to run valgrind on my processes that import the latest pyarrow ( python ). I think its due to an Avx512 instruction that they recently added, which valgrind doesn't support. I just tried compiling trunk version of valgrind to see if its in but I still seem to hit the error with the latest build. This is the error from valgrind: vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x44 0x24 0xA 0xC7 0x43 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==32035== valgrind: Unrecognised instruction at address 0x1085ea85. ==32035== at 0x1085EA85: arrow::compute::internal::RegisterScalarAggregateSumAvx512(arrow::compute::FunctionRegistry*) (in /home/ra7293/user/hfalgo_csp/.venvs/PY36/build_tools_venv/lib/libarrow.so.100.1.0) ==32035== by 0x1067967C: arrow::compute::GetFunctionRegistry() (in /home/ra7293/user/hfalgo_csp/.venvs/PY36/build_tools_venv/lib/libarrow.so.100.1.0) ==32035== by 0x51CCDF0F: __pyx_pw_7pyarrow_8_compute_16FunctionRegistry_1__init__(_object*, _object*, _object*) (in /home/ra7293/user/hfalgo_csp/.venvs/PY36/build_tools_venv/lib/python3.6/site-packages/pyarrow/_compute.cpython-36m-x86_64-linux-gnu.so) Please let me know if this is something that can be added and if you need any more information. I love valgrind and use it regularly, I really hope to see this added as soon as possible. Thank you for this awesome tool! - Rob DISCLAIMER: This e-mail message and any attachments are intended solely for the use of the individual or entity to which it is addressed and may contain information that is confidential or legally privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and permanently delete this message and any attachments. |
|
From: Julian S. <jse...@gm...> - 2021-11-23 10:33:07
|
Greetings developers, A couple of us thought that it would be nice to have, from time to time, a group video call for developers. So that we can talk, discuss the status of work, problems, who needs help with what, and generally just associate faces and personalities with names. The call is at Fri 26 Nov, 1700 UTC / 1800 CET / 0900 PST. You can join from your web browser (meaning, it runs within the browser) at https://meet.jit.si/ValgrindDevMeeting. See you there! J |
|
From: Paul F. <pa...@so...> - 2021-11-22 20:40:38
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=49d6d73c2506dbd0b089ed450154e5f6d5b73fc7 commit 49d6d73c2506dbd0b089ed450154e5f6d5b73fc7 Author: Paul Floyd <pj...@wa...> Date: Mon Nov 22 04:12:16 2021 +0100 Add missing syscall wrapper on Solaris I tried to test drd/tests/pth_mutex_signal on Solaris (you never know) but encountered a missing syscall wrapper. So this adds a very basic wrapper for lwp_mutex_unlock. Also update a Solaris expected that I missed amongst the FreeBSD changes. Diff: --- coregrind/m_syswrap/syswrap-solaris.c | 17 +++++++++++++++++ gdbserver_tests/solaris/nlcontrolc.stdoutB.exp | 4 ++-- include/vki/vki-scnums-solaris.h | 2 +- 3 files changed, 20 insertions(+), 3 deletions(-) diff --git a/coregrind/m_syswrap/syswrap-solaris.c b/coregrind/m_syswrap/syswrap-solaris.c index 5dba90ac87..d1ce0fd6bb 100644 --- a/coregrind/m_syswrap/syswrap-solaris.c +++ b/coregrind/m_syswrap/syswrap-solaris.c @@ -1067,6 +1067,7 @@ DECL_TEMPLATE(solaris, sys_getpeername); DECL_TEMPLATE(solaris, sys_getsockname); DECL_TEMPLATE(solaris, sys_getsockopt); DECL_TEMPLATE(solaris, sys_setsockopt); +DECL_TEMPLATE(solaris, sys_lwp_mutex_unlock); DECL_TEMPLATE(solaris, sys_lwp_mutex_register); DECL_TEMPLATE(solaris, sys_uucopy); DECL_TEMPLATE(solaris, sys_umount2); @@ -10635,6 +10636,21 @@ PRE(sys_lwp_mutex_register) PRE_FIELD_READ("lwp_mutex_register(mp->mutex_type)", mp->vki_mutex_type); } +PRE(sys_lwp_mutex_unlock) +{ + /* int lwp_mutex_unlock(lwp_mutex_t *lp); */ + vki_lwp_mutex_t *lp = (vki_lwp_mutex_t*)ARG1; + PRINT("sys_lwp_mutex_unlock ( %#lx )", ARG1); + PRE_REG_READ1(int, "lwp_mutex_unlock", lwp_mutex_t *, lp); + PRE_MEM_READ("lwp_mutex_unlock(lp)", (Addr)lp, sizeof(vki_lwp_mutex_t)); + PRE_MEM_WRITE("lwp_mutex_unlock(lp)", (Addr)lp, sizeof(vki_lwp_mutex_t)); +} + +POST(sys_lwp_mutex_unlock) +{ + POST_MEM_WRITE(ARG1, sizeof(vki_lwp_mutex_t)); +} + PRE(sys_uucopy) { /* int uucopy(const void *s1, void *s2, size_t n); */ @@ -11027,6 +11043,7 @@ static SyscallTableEntry syscall_table[] = { SOLXY(__NR_getsockname, sys_getsockname), /* 244 */ SOLXY(__NR_getsockopt, sys_getsockopt), /* 245 */ SOLX_(__NR_setsockopt, sys_setsockopt), /* 246 */ + SOLXY(__NR_lwp_mutex_unlock, sys_lwp_mutex_unlock), /* 250 */ SOLX_(__NR_lwp_mutex_register, sys_lwp_mutex_register), /* 252 */ SOLXY(__NR_uucopy, sys_uucopy), /* 254 */ SOLX_(__NR_umount2, sys_umount2) /* 255 */ diff --git a/gdbserver_tests/solaris/nlcontrolc.stdoutB.exp b/gdbserver_tests/solaris/nlcontrolc.stdoutB.exp index ca29a44e10..d3684dfbf0 100644 --- a/gdbserver_tests/solaris/nlcontrolc.stdoutB.exp +++ b/gdbserver_tests/solaris/nlcontrolc.stdoutB.exp @@ -5,8 +5,8 @@ Program received signal SIGTRAP, Trace/breakpoint trap. Now threads are burning CPU Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. -0x........ in do_burn () at sleepers.c:41 -41 for (i = 0; i < burn; i++) loopnr++; +do_burn () at sleepers.c:40 +40 for (i = 0; i < burn; i++) loopnr++; $1 = 0 $2 = 0 $3 = 0 diff --git a/include/vki/vki-scnums-solaris.h b/include/vki/vki-scnums-solaris.h index d043dd8bcc..99388091a8 100644 --- a/include/vki/vki-scnums-solaris.h +++ b/include/vki/vki-scnums-solaris.h @@ -300,7 +300,7 @@ //#define __NR_sockconfig SYS_sockconfig //#define __NR_ntp_gettime SYS_ntp_gettime //#define __NR_ntp_adjtime SYS_ntp_adjtime -//#define __NR_lwp_mutex_unlock SYS_lwp_mutex_unlock +#define __NR_lwp_mutex_unlock SYS_lwp_mutex_unlock //#define __NR_lwp_mutex_trylock SYS_lwp_mutex_trylock #define __NR_lwp_mutex_register SYS_lwp_mutex_register //#define __NR_cladm SYS_cladm |
|
From: Mark W. <ma...@so...> - 2021-11-22 12:16:18
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=542447d4708d4418a08e678dcf467af92b90b7ad commit 542447d4708d4418a08e678dcf467af92b90b7ad Author: Mark Wielaard <ma...@kl...> Date: Mon Nov 22 13:07:59 2021 +0100 readdwarf3.c (parse_inl_DIE) inlined_subroutine can appear in namespaces This was broken by commit 75e3ef0f3 "readdwarf3: Skip units without addresses when looking for inlined functions". Specifically by this part: "Also use skip_DIE instead of read_DIE when not parsing (skipping) children" rustc puts concrete function instances in namespaces (which is allowed in DWARF since there is no strict separation between type declarations and program scope entries in a DIE tree), the inline parser didn't expect this and so skipped any DIE under a namespace entry. This wasn't an issue before because "skipping" a DIE tree was done by reading it, so it wasn't actually skipped. But now that we really skip the DIE (sub)tree (which is faster than actually parsing it) some entries were missed in the rustc case. https://bugs.kde.org/show_bug.cgi?id=445668 Diff: --- NEWS | 1 + coregrind/m_debuginfo/readdwarf3.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 567f19daa8..76e598fb7f 100644 --- a/NEWS +++ b/NEWS @@ -53,6 +53,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 445300 [PATCH] Fix building tests with Musl 445354 arm64 backend: incorrect code emitted for doubleword CAS 445415 arm64 front end: alignment checks missing for atomic instructions +445668 Inline stack frame generation is broken for Rust binaries To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/coregrind/m_debuginfo/readdwarf3.c b/coregrind/m_debuginfo/readdwarf3.c index 18eecea9f3..5489f8d135 100644 --- a/coregrind/m_debuginfo/readdwarf3.c +++ b/coregrind/m_debuginfo/readdwarf3.c @@ -3358,7 +3358,7 @@ static Bool parse_inl_DIE ( // might maybe contain a DW_TAG_inlined_subroutine: Bool ret = (unit_has_addrs || dtag == DW_TAG_lexical_block || dtag == DW_TAG_subprogram - || dtag == DW_TAG_inlined_subroutine); + || dtag == DW_TAG_inlined_subroutine || dtag == DW_TAG_namespace); return ret; bad_DIE: |
|
From: Paul F. <pa...@so...> - 2021-11-22 07:45:37
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=e484eee0bdf0a77fc260b69ac7495352e1a972e3 commit e484eee0bdf0a77fc260b69ac7495352e1a972e3 Author: Paul Floyd <pj...@wa...> Date: Mon Nov 22 08:42:53 2021 +0100 Bug 445300 [PATCH] Fix building tests with Musl Patch contributed by Alyssa Ross <hi...@al...> Diff: --- NEWS | 1 + configure.ac | 9 +++++++++ helgrind/tests/tc20_verifywrap.c | 10 +++++----- memcheck/tests/linux/sys-statx.c | 5 ++--- memcheck/tests/str_tester.c | 5 ++--- 5 files changed, 19 insertions(+), 11 deletions(-) diff --git a/NEWS b/NEWS index 708c6e1df7..567f19daa8 100644 --- a/NEWS +++ b/NEWS @@ -50,6 +50,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. 444836 PPC, pstq instruction for R=1 is not storing to the correct address. 445032 valgrind/memcheck crash with SIGSEGV when SIGVTALRM timer used and libthr.so associated +445300 [PATCH] Fix building tests with Musl 445354 arm64 backend: incorrect code emitted for doubleword CAS 445415 arm64 front end: alignment checks missing for atomic instructions diff --git a/configure.ac b/configure.ac index cb836dbff5..4623d12b5b 100755 --- a/configure.ac +++ b/configure.ac @@ -4608,6 +4608,14 @@ AC_TYPE_OFF_T AC_TYPE_SIZE_T AC_HEADER_TIME +AC_CHECK_TYPE([struct statx], [ + AC_DEFINE([HAVE_STRUCT_STATX_IN_SYS_STAT_H], 1, + [Define to 1 if <sys/stat.h> declares struct statx.]) +], [], [ + #define _GNU_SOURCE + #include <sys/stat.h> +]) + #---------------------------------------------------------------------------- # Checks for library functions. @@ -4645,6 +4653,7 @@ AC_CHECK_FUNCS([ \ pthread_yield \ pwritev \ pwritev2 \ + rawmemchr \ readlinkat \ semtimedop \ setcontext \ diff --git a/helgrind/tests/tc20_verifywrap.c b/helgrind/tests/tc20_verifywrap.c index ae97bde8d3..5f8b5b3810 100644 --- a/helgrind/tests/tc20_verifywrap.c +++ b/helgrind/tests/tc20_verifywrap.c @@ -20,14 +20,14 @@ #if !defined(__APPLE__) && !defined(__FreeBSD__) -#if defined(__sun__) -/* Fake __GLIBC_PREREQ on Solaris. Pretend glibc >= 2.4. */ -# define __GLIBC_PREREQ -#else +#if defined(__GLIBC__) #if !defined(__GLIBC_PREREQ) # error "This program needs __GLIBC_PREREQ (in /usr/include/features.h)" #endif -#endif /* __sun__ */ +#else +/* Fake __GLIBC_PREREQ. Pretend glibc >= 2.4. */ +# define __GLIBC_PREREQ +#endif /* __GLIBC__ */ typedef union { pthread_spinlock_t spinlock; diff --git a/memcheck/tests/linux/sys-statx.c b/memcheck/tests/linux/sys-statx.c index fe9f9ba451..fcbc2e0de7 100644 --- a/memcheck/tests/linux/sys-statx.c +++ b/memcheck/tests/linux/sys-statx.c @@ -1,5 +1,6 @@ /* Test (somewhat) stats and stat. */ #define _GNU_SOURCE +#include "config.h" #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> @@ -7,9 +8,7 @@ #include <assert.h> #include <string.h> #include <sys/syscall.h> -#if __GLIBC_PREREQ(2,28) -/* struct statx provided in sys/stat.h */ -#else +#ifndef HAVE_STRUCT_STATX_IN_SYS_STAT_H #include <linux/stat.h> #endif #include <errno.h> diff --git a/memcheck/tests/str_tester.c b/memcheck/tests/str_tester.c index 7c2ff1e62e..01354eb132 100644 --- a/memcheck/tests/str_tester.c +++ b/memcheck/tests/str_tester.c @@ -503,8 +503,7 @@ test_strchrnul (void) } #endif -// DDD: better done by testing for the function. -#if !defined(__APPLE__) && !defined(__sun) && !defined(__FreeBSD__) +#ifdef HAVE_RAWMEMCHR static void test_rawmemchr (void) { @@ -1451,7 +1450,7 @@ main (void) test_strchrnul (); # endif -# if !defined(__APPLE__) && !defined(__sun) && !defined(__FreeBSD__) +# ifdef HAVE_RAWMEMCHR /* rawmemchr. */ test_rawmemchr (); # endif |
|
From: Paul F. <pa...@so...> - 2021-11-22 07:41:02
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=02ce9addfa9de9adb29c76864a0382fc75901222 commit 02ce9addfa9de9adb29c76864a0382fc75901222 Author: Paul Floyd <pj...@wa...> Date: Mon Nov 22 08:40:07 2021 +0100 Add drd pthread_mutex_signal testcase executable to .gitignore Diff: --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 57ba9ca92a..fd85516b28 100644 --- a/.gitignore +++ b/.gitignore @@ -426,6 +426,7 @@ /drd/tests/pth_detached_sem /drd/tests/pth_inconsistent_cond_wait /drd/tests/pth_mutex_reinit +/drd/tests/pth_mutex_signal /drd/tests/pth_process_shared_mutex /drd/tests/pth_spinlock /drd/tests/pth_uninitialized_cond |
|
From: Paul F. <pj...@wa...> - 2021-11-21 16:46:08
|
Hi all I've been looking at https://bugs.kde.org/show_bug.cgi?id=445743 "The impossible happened: mutex is locked simultaneously by two threads" while using mutexes with priority inheritance and signals. I did think that there might be a bug in the client code since the man page says that pthread_mutex_lock can fail with EINVAL The mutex was created with the protocol attribute having the value PTHREAD_PRIO_PROTECT and the calling thread's priority is higher than the mutex's current priority ceiling. but looking more closely I don't think that PTHREAD_PRIO_INHERIT can fail with EINVAL. I do get EINVAL on FreeBSD though. The mutex mechanisms used by both Linux and FreeBSD seem failrly similar. * mutex variable initialized to 0 * first locker just uses an atomic compare and swap to set the mutex to one * if there is a second locker, fall back to the kernel (futex or _umtx_op) Here are some traces (with null grind, trimmed a bit for brevity) thread created sleeping PJF: main sleeps SYSCALL[4696,1](230) sys_clock_nanosleep( 0, 0, 0x1ffefffce0, 0x0 ) --> [async] ... PJF: thread cmpxcg failed, get the futex SYSCALL[4696,2](273) sys_set_robust_list ( 0x4acf920, 24 )[sync] --> Success(0x0) contender trying to lock mutex PJF: thread blocks on mutex SYSCALL[4696,2](202) sys_futex ( 0x1ffefffdf0, 134, 0, 0x0, 0x0 ) --> [async] ... PJF: main sleep ends SYSCALL[4696,1](230) ... [async] --> Success(0x0) signalling SYSCALL[4696,1](234) sys_tgkill ( 4696, 4697, 62 ) --> [async] ... SYSCALL[4696,1](234) ... [async] --> Success(0x0) joining thread PJF: what is this? it's on the main thread, I guess pthread_join uses a mutex SYSCALL[4696,1](202) sys_futex ( 0x4acf910, 265, 4697, 0x0, 0x0 ) --> [async] ... nullHandler running PJF: sigreturn SYSCALL[4696,2](15) sys_rt_sigreturn ( ) --> [pre-success] NoWriteResult PJF: I would expect futex EINTR here and to resume PJF: but instead pthread_mutex_lock has returned without error contender locked mutex PJF: thread continues to end and main joins it A+ Paul |
|
From: Mark W. <ma...@so...> - 2021-11-21 14:34:42
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=5db4f35edf1d40de25a587442476a01862a51acb commit 5db4f35edf1d40de25a587442476a01862a51acb Author: Mark Wielaard <ma...@kl...> Date: Sun Nov 21 15:25:14 2021 +0100 drd-manual.xml: Fix link to libstdc++ manual GLIBCXX_FORCE_NEW reference. Diff: --- drd/docs/drd-manual.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drd/docs/drd-manual.xml b/drd/docs/drd-manual.xml index 8fe1903e6c..59fbb11e40 100644 --- a/drd/docs/drd-manual.xml +++ b/drd/docs/drd-manual.xml @@ -1529,7 +1529,7 @@ to use standard memory allocation functions instead of memory pools by setting the environment variable <literal>GLIBCXX_FORCE_NEW</literal>. For more information, see also the <ulink -url="http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt04ch11.html">libstdc++ +url="https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html">libstdc++ manual</ulink>. </para> |
|
From: Bart V. A. <bva...@so...> - 2021-11-20 22:30:13
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=bf0579a44a448eebfdd4af1c6f309221b8662633 commit bf0579a44a448eebfdd4af1c6f309221b8662633 Author: Bart Van Assche <bva...@ac...> Date: Sat Nov 20 13:59:22 2021 -0800 drd: Add a test program that interrupts pthread_mutex_lock() This test fails, probably due to differences between native signal handling and signal handling in the Valgrind core. Diff: --- drd/tests/Makefile.am | 3 ++ drd/tests/pth_mutex_signal.c | 95 +++++++++++++++++++++++++++++++++++ drd/tests/pth_mutex_signal.stderr.exp | 15 ++++++ drd/tests/pth_mutex_signal.vgtest | 3 ++ 4 files changed, 116 insertions(+) diff --git a/drd/tests/Makefile.am b/drd/tests/Makefile.am index c804391e81..ac487def3c 100755 --- a/drd/tests/Makefile.am +++ b/drd/tests/Makefile.am @@ -227,6 +227,8 @@ EXTRA_DIST = \ pth_inconsistent_cond_wait.vgtest \ pth_mutex_reinit.stderr.exp \ pth_mutex_reinit.vgtest \ + pth_mutex_signal.stderr.exp \ + pth_mutex_signal.vgtest \ pth_once.stderr.exp \ pth_once.vgtest \ pth_process_shared_mutex.stderr.exp \ @@ -410,6 +412,7 @@ check_PROGRAMS = \ pth_detached3 \ pth_inconsistent_cond_wait \ pth_mutex_reinit \ + pth_mutex_signal \ pth_process_shared_mutex \ recursive_mutex \ rwlock_race \ diff --git a/drd/tests/pth_mutex_signal.c b/drd/tests/pth_mutex_signal.c new file mode 100644 index 0000000000..ec74696953 --- /dev/null +++ b/drd/tests/pth_mutex_signal.c @@ -0,0 +1,95 @@ +/* + * See also https://bugs.kde.org/show_bug.cgi?id=445743. + */ + +#include <assert.h> +#include <pthread.h> +#include <signal.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> + +#define STACK_SIZE 1024 * 512 +#define NATIVE_IO_INTERRUPT_SIGNAL (SIGRTMAX - 2) +#define LONG_SLEEP_TIME 1000000 + +void *contender_start(void *arg) +{ + pthread_mutex_t *mutex = arg; + int ret; + + ret = pthread_mutex_lock(mutex); + assert(ret == 0); + fprintf(stderr, "contender locked mutex\n"); + fprintf(stderr, "contender unlocking mutex\n"); + pthread_mutex_unlock(mutex); + fprintf(stderr, "contender unlocked mutex\n"); + return NULL; +} + +void nullHandler(int signal, siginfo_t *info, void *context) +{ + static const char *msg = "nullHandler running\n"; + + write(STDERR_FILENO, msg, strlen(msg)); +} + +int main () +{ + pthread_mutex_t mutex; + pthread_mutexattr_t mutex_attr; + pthread_attr_t thread_attr_contender; + pthread_t contender; + struct sigaction signalAction = { }; + + // install signal handler + signalAction.sa_sigaction = nullHandler; + sigfillset(&signalAction.sa_mask); + signalAction.sa_flags = 0; + sigaction(NATIVE_IO_INTERRUPT_SIGNAL, &signalAction, NULL); + + // initialize the mutex + pthread_mutexattr_init(&mutex_attr); + pthread_mutexattr_setprotocol(&mutex_attr, PTHREAD_PRIO_INHERIT); + pthread_mutex_init(&mutex, &mutex_attr); + fprintf(stderr, "mutex initialized\n"); + + // lock mutex + pthread_mutex_lock(&mutex); + + // init and create contender + pthread_attr_init(&thread_attr_contender); + pthread_attr_setstacksize(&thread_attr_contender, STACK_SIZE); + pthread_attr_setinheritsched(&thread_attr_contender, PTHREAD_EXPLICIT_SCHED); + fprintf(stderr, "thread attributes initialized\n"); + if (pthread_create(&contender, &thread_attr_contender, &contender_start, + &mutex) != 0) { + fprintf(stderr, "failed to create thread\n"); + return 1; + } + fprintf(stderr, "thread created\n"); + pthread_attr_destroy(&thread_attr_contender); + + // wait until the thread is sleeping inside pthread_mutex_lock(). + fprintf(stderr, "sleeping\n"); + usleep(LONG_SLEEP_TIME); + + // signal thread + fprintf(stderr, "signalling\n"); + pthread_kill(contender, NATIVE_IO_INTERRUPT_SIGNAL); + + fprintf(stderr, "sleeping\n"); + usleep(LONG_SLEEP_TIME); + + fprintf(stderr, "unlocking\n"); + pthread_mutex_unlock(&mutex); + + usleep(LONG_SLEEP_TIME); + + // finally wait for the thread + fprintf(stderr, "joining thread\n"); + pthread_join(contender, NULL); + + return 0; +} diff --git a/drd/tests/pth_mutex_signal.stderr.exp b/drd/tests/pth_mutex_signal.stderr.exp new file mode 100644 index 0000000000..63f38b08cf --- /dev/null +++ b/drd/tests/pth_mutex_signal.stderr.exp @@ -0,0 +1,15 @@ + +mutex initialized +thread attributes initialized +thread created +sleeping +signalling +sleeping +nullHandler running +unlocking +contender locked mutex +contender unlocking mutex +contender unlocked mutex +joining thread + +ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) diff --git a/drd/tests/pth_mutex_signal.vgtest b/drd/tests/pth_mutex_signal.vgtest new file mode 100644 index 0000000000..aaf967bb4a --- /dev/null +++ b/drd/tests/pth_mutex_signal.vgtest @@ -0,0 +1,3 @@ +prereq: ./supported_libpthread && [ -e pth_mutex_signal ] +vgopts: --check-stack-var=yes --read-var-info=yes +prog: pth_mutex_signal |
|
From: Mark W. <ma...@so...> - 2021-11-19 14:17:57
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=8ad4c01880670b66d7b89fb0984bab2d26162ab8 commit 8ad4c01880670b66d7b89fb0984bab2d26162ab8 Author: Mark Wielaard <ma...@kl...> Date: Fri Nov 19 15:00:27 2021 +0100 memcheck/tests/libstdc++.supp: rename suppression The name malloc-leaks-cxx-stl-string-classes-debug was confusing since the suppression wasn't a leak, not part of stl, string, classes or debug. Rename it to libstdcxx-emergency-eh-alloc-pool to indicate it is part of the emergency exception handling memory pool. Note that suppression is only needed for some test cases, normally the pool is cleaned up as part of cxx_freeres. Diff: --- memcheck/tests/libstdc++.supp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/memcheck/tests/libstdc++.supp b/memcheck/tests/libstdc++.supp index 852d8ab0b6..2cac057305 100644 --- a/memcheck/tests/libstdc++.supp +++ b/memcheck/tests/libstdc++.supp @@ -69,7 +69,7 @@ fun:call_init* } { - malloc-leaks-cxx-stl-string-classes-debug + libstdcxx-emergency-eh-alloc-pool Memcheck:Leak match-leak-kinds: reachable fun:malloc |
|
From: Paul F. <pa...@so...> - 2021-11-19 07:36:18
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=9abfed23c0d430aafb85de6397d171316c982792 commit 9abfed23c0d430aafb85de6397d171316c982792 Author: Paul Floyd <pj...@wa...> Date: Fri Nov 19 08:34:53 2021 +0100 Bug 445504 Using C++ condition_variable results in bogus "mutex is locked simultaneously by two threads" warning(edit) Add intercepts for pthread_cond_clockwait to DRD and Helgrind Also testcase from bugzilla done by Bart, with configure check Diff: --- .gitignore | 1 + configure.ac | 21 ++++++++++++ drd/drd_pthread_intercepts.c | 24 +++++++++++++ drd/tests/Makefile.am | 9 +++++ drd/tests/condvar.cpp | 55 +++++++++++++++++++++++++++++ drd/tests/condvar.stderr.exp | 5 +++ drd/tests/condvar.vgtest | 3 ++ helgrind/hg_intercepts.c | 82 ++++++++++++++++++++++++++++++++++++++++++++ 8 files changed, 200 insertions(+) diff --git a/.gitignore b/.gitignore index 5ab4d74ebe..57ba9ca92a 100644 --- a/.gitignore +++ b/.gitignore @@ -384,6 +384,7 @@ /drd/tests/bug322621 /drd/tests/circular_buffer /drd/tests/concurrent_close +/drd/tests/condvar /drd/tests/custom_alloc /drd/tests/dlopen_lib.so /drd/tests/dlopen_main diff --git a/configure.ac b/configure.ac index e7381f205d..cb836dbff5 100755 --- a/configure.ac +++ b/configure.ac @@ -1989,6 +1989,27 @@ AC_LANG(C) AM_CONDITIONAL(CXX_CAN_INCLUDE_THREAD_HEADER, test x$ac_cxx_can_include_thread_header = xyes) +# Check whether compiler can process #include <condition_variable> without errors + +AC_MSG_CHECKING([that C++ compiler can include <condition_variable> header file]) +AC_LANG(C++) +safe_CXXFLAGS=$CXXFLAGS +CXXFLAGS=-std=c++0x + +AC_COMPILE_IFELSE([AC_LANG_SOURCE([ +#include <condition_variable> +])], +[ +ac_cxx_can_include_condition_variable_header=yes +AC_MSG_RESULT([yes]) +], [ +ac_cxx_can_include_condition_variable_header=no +AC_MSG_RESULT([no]) +]) +CXXFLAGS=$safe_CXXFLAGS +AC_LANG(C) + +AM_CONDITIONAL(CXX_CAN_INCLUDE_CONDITION_VARIABLE_HEADER, test x$ac_cxx_can_include_condition_variable_header = xyes) # On aarch64 before glibc 2.20 we would get the kernel user_pt_regs instead # of the user_regs_struct from sys/user.h. They are structurally the same diff --git a/drd/drd_pthread_intercepts.c b/drd/drd_pthread_intercepts.c index 8b44543645..95127b42c6 100644 --- a/drd/drd_pthread_intercepts.c +++ b/drd/drd_pthread_intercepts.c @@ -1175,6 +1175,30 @@ PTH_FUNCS(int, condZureltimedwait, pthread_cond_timedwait_intercept, (cond, mutex, timeout)); #endif /* VGO_solaris */ + +static __always_inline +int pthread_cond_clockwait_intercept(pthread_cond_t *cond, + pthread_mutex_t *mutex, + clockid_t clockid, + const struct timespec* abstime) +{ + int ret; + OrigFn fn; + VALGRIND_GET_ORIG_FN(fn); + VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__PRE_COND_WAIT, + cond, mutex, DRD_(mutex_type)(mutex), 0, 0); + CALL_FN_W_WWWW(ret, fn, cond, mutex, clockid, abstime); + VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__POST_COND_WAIT, + cond, mutex, 1, 0, 0); + return ret; +} + +PTH_FUNCS(int, pthreadZucondZuclockwait, pthread_cond_clockwait_intercept, + (pthread_cond_t *cond, pthread_mutex_t *mutex, + clockid_t clockid, const struct timespec* abstime), + (cond, mutex, clockid, abstime)); + + // NOTE: be careful to intercept only pthread_cond_signal() and not Darwin's // pthread_cond_signal_thread_np(). The former accepts one argument; the latter // two. Intercepting all pthread_cond_signal* functions will cause only one diff --git a/drd/tests/Makefile.am b/drd/tests/Makefile.am index 4cb2f7f84a..c804391e81 100755 --- a/drd/tests/Makefile.am +++ b/drd/tests/Makefile.am @@ -105,6 +105,8 @@ EXTRA_DIST = \ circular_buffer.vgtest \ concurrent_close.stderr.exp \ concurrent_close.vgtest \ + condvar.stderr.exp \ + condvar.vgtest \ custom_alloc.stderr.exp \ custom_alloc.vgtest \ custom_alloc_fiw.stderr.exp \ @@ -458,6 +460,11 @@ check_PROGRAMS += \ endif endif +if CXX_CAN_INCLUDE_CONDITION_VARIABLE_HEADER +check_PROGRAMS += \ + condvar +endif + if HAVE_OPENMP check_PROGRAMS += omp_matinv omp_prime omp_printf endif @@ -502,6 +509,8 @@ LDADD = -lpthread bug322621_SOURCES = bug322621.cpp +condvar_SOURCES = condvar.cpp +condvar_CXXFLAGS = $(AM_CXXFLAGS) -std=c++0x concurrent_close_SOURCES = concurrent_close.cpp if !VGCONF_OS_IS_FREEBSD dlopen_main_LDADD = -ldl diff --git a/drd/tests/condvar.cpp b/drd/tests/condvar.cpp new file mode 100644 index 0000000000..18ecb3f8a4 --- /dev/null +++ b/drd/tests/condvar.cpp @@ -0,0 +1,55 @@ +/* See also https://bugs.kde.org/show_bug.cgi?id=445504 */ + +#include <condition_variable> +#include <future> +#include <iostream> +#include <mutex> +#include <thread> +#include <vector> + +using lock_guard = std::lock_guard<std::mutex>; +using unique_lock = std::unique_lock<std::mutex>; + +struct state { + std::mutex m; + std::vector<int> v; + std::condition_variable cv; + + state() { + // Call pthread_cond_init() explicitly to let DRD know about 'cv'. + pthread_cond_init(cv.native_handle(), NULL); + } +}; + +void other_thread(state *sp) { + state &s = *sp; + std::cerr << "Other thread: waiting for notify\n"; + unique_lock l{s.m}; + while (true) { + if (s.cv.wait_for(l, std::chrono::seconds(3)) != + std::cv_status::timeout) { + std::cerr << "Other thread: notified\n"; + break; + } + } + return; +} + + +int main() { + state s; + auto future = std::async(std::launch::async, other_thread, &s); + + if (future.wait_for(std::chrono::seconds(1)) != std::future_status::timeout) { + std::cerr << "Main: other thread returned too early!\n"; + return 2; + } + + { + std::lock_guard<std::mutex> g{s.m}; + s.v.push_back(1); + s.v.push_back(2); + s.cv.notify_all(); + } + return 0; +} diff --git a/drd/tests/condvar.stderr.exp b/drd/tests/condvar.stderr.exp new file mode 100644 index 0000000000..be1de9f973 --- /dev/null +++ b/drd/tests/condvar.stderr.exp @@ -0,0 +1,5 @@ + +Other thread: waiting for notify +Other thread: notified + +ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) diff --git a/drd/tests/condvar.vgtest b/drd/tests/condvar.vgtest new file mode 100644 index 0000000000..2e7d49f5a6 --- /dev/null +++ b/drd/tests/condvar.vgtest @@ -0,0 +1,3 @@ +prereq: ./supported_libpthread && [ -e condvar ] +vgopts: --check-stack-var=yes --read-var-info=yes +prog: condvar diff --git a/helgrind/hg_intercepts.c b/helgrind/hg_intercepts.c index 866efdbaa8..49c3ddcd9e 100644 --- a/helgrind/hg_intercepts.c +++ b/helgrind/hg_intercepts.c @@ -1409,6 +1409,88 @@ static int pthread_cond_timedwait_WRK(pthread_cond_t* cond, # error "Unsupported OS" #endif +//----------------------------------------------------------- +// glibc: pthread_cond_clockwait +// +__attribute__((noinline)) +static int pthread_cond_clockwait_WRK(pthread_cond_t* cond, + pthread_mutex_t* mutex, + clockid_t clockid, + struct timespec* abstime, + int timeout_error) +{ + int ret; + OrigFn fn; + unsigned long mutex_is_valid; + Bool abstime_is_valid; + VALGRIND_GET_ORIG_FN(fn); + + if (TRACE_PTH_FNS) { + fprintf(stderr, "<< pthread_cond_clockwait %p %p %p", + cond, mutex, abstime); + fflush(stderr); + } + + /* Tell the tool a cond-wait is about to happen, so it can check + for bogus argument values. In return it tells us whether it + thinks the mutex is valid or not. */ + DO_CREQ_W_WW(mutex_is_valid, + _VG_USERREQ__HG_PTHREAD_COND_WAIT_PRE, + pthread_cond_t*,cond, pthread_mutex_t*,mutex); + assert(mutex_is_valid == 1 || mutex_is_valid == 0); + + abstime_is_valid = abstime->tv_nsec >= 0 && abstime->tv_nsec < 1000000000; + + /* Tell the tool we're about to drop the mutex. This reflects the + fact that in a cond_wait, we show up holding the mutex, and the + call atomically drops the mutex and waits for the cv to be + signalled. */ + if (mutex_is_valid && abstime_is_valid) { + DO_CREQ_v_W(_VG_USERREQ__HG_PTHREAD_MUTEX_UNLOCK_PRE, + pthread_mutex_t*,mutex); + } + + CALL_FN_W_WWWW(ret, fn, cond,mutex,clockid,abstime); + + if (mutex_is_valid && !abstime_is_valid && ret != EINVAL) { + DO_PthAPIerror("Bug in libpthread: pthread_cond_clockwait " + "invalid abstime did not cause" + " EINVAL", ret); + } + + if (mutex_is_valid && abstime_is_valid) { + /* and now we have the mutex again if (ret == 0 || ret == timeout) */ + DO_CREQ_v_WW(_VG_USERREQ__HG_PTHREAD_MUTEX_LOCK_POST, + pthread_mutex_t *, mutex, + long, (ret == 0 || ret == timeout_error) ? True : False); + } + + DO_CREQ_v_WWWW(_VG_USERREQ__HG_PTHREAD_COND_WAIT_POST, + pthread_cond_t*,cond, pthread_mutex_t*,mutex, + long,ret == timeout_error, + long, (ret == 0 || ret == timeout_error) && mutex_is_valid + ? True : False); + + if (ret != 0 && ret != timeout_error) { + DO_PthAPIerror( "pthread_cond_clockwait", ret ); + } + + if (TRACE_PTH_FNS) { + fprintf(stderr, " cotimedwait -> %d >>\n", ret); + } + + return ret; +} + +#if defined(VGO_linux) + PTH_FUNC(int, pthreadZucondZuclockwait, // pthread_cond_clockwait + pthread_cond_t* cond, pthread_mutex_t* mutex, + clockid_t clockid, + struct timespec* abstime) { + return pthread_cond_clockwait_WRK(cond, mutex, clockid, abstime, ETIMEDOUT); + } +#endif + //----------------------------------------------------------- // glibc: pthread_cond_signal@GLIBC_2.0 |
|
From: Paul F. <pa...@so...> - 2021-11-18 18:53:52
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=b754b7b48a71ffa7b57272033f42b43d09d31cb4 commit b754b7b48a71ffa7b57272033f42b43d09d31cb4 Author: Paul Floyd <pj...@wa...> Date: Thu Nov 18 19:52:46 2021 +0100 Add some details for running regtests on FreeBSD. Diff: --- README.freebsd | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/README.freebsd b/README.freebsd index c6e6818211..8a8981439c 100644 --- a/README.freebsd +++ b/README.freebsd @@ -126,6 +126,22 @@ These are much easier. They just contain a POST_MEM_WRITE macro for each output argument. +1. Running regression tests + +In order to run all of the regression tests you will need to install +the following packages +gdb +gsed + +In addition to running "make" you will need to run +"make check" to build the regression test exectutables +and "make regtest". Again, more details can be seen in +README_DEVELOPERS. + +If you want to run the 'nightly' script (see nightly/README.txt) +you will need to install coreutils and modify the +nightly/conf/freebsd.* files. The default configuration +sends an e-mail to the valgrind-testresults mailing list. Feedback ~~~~~~~~ |
|
From: Julian S. <jse...@gm...> - 2021-11-18 07:36:44
|
(With apologies for the huge delay on this message). J We are pleased to announce a new release of Valgrind, version 3.18.1, available from http://valgrind.org/downloads/current.html. 3.18.1 fixes a number of bugs and adds support for glibc-2.34, and for new platforms x86/FreeBSD and amd64/FreeBSD. Debuginfo reading is faster, and Rust demangling has been improved. For PPC64, ISA 3.1 support has been completed, and some newer ARM64 and S390 instructions are also supported. See the release notes below for details of changes. Note, 3.18.0 had no formal release -- it was pulled at the last minute due to a packaging problem. 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 Release 3.18.0 (15 Oct 2021) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 libiberty demangler has been updated, which brings support for Rust v0 name demangling * __libc_freeres isn't called anymore after the program recieves a fatal signal. Causing some internal glibc resources to hang around, but preventing any crashes after the program has ended. * The DWARF reader is now very much faster at startup when just --read-inline-info=yes (the default in most cases) is given. * glibc 2.34, which moved various functions from libpthread.so into libc.so, is now supported. * ================== PLATFORM CHANGES ================= * arm64: - v8.2 scalar and vector FABD, FACGE, FACGT and FADD. - v8.2 FP compare & conditional compare instructions. - Zero variants of v8.2 FP compare instructions. * s390: - Support the miscellaneous-instruction-extensions facility 3 and the vector-enhancements facility 2. This enables programs compiled with "-march=arch13" or "-march=z15" to be executed under Valgrind. * ppc64: - ISA 3.1 support is now complete - ISA 3.0 support for the darn instruction added. - ISA 3.0 support for the vector system call instruction scv added. - ISA 3.0 support for the copy, paste and cpabort instructions added. * Support for X86/FreeBSD and AMD64/FreeBSD has been added. * ==================== OTHER CHANGES ==================== * Memcheck on amd64: minor fixes to remove some false positive undef-value errors * ==================== 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. 208531 [PATCH]: FreeBSD support for valgrind 368960 WARNING: unhandled amd64-linux syscall: 163 (acct) 407589 [Linux] Add support for C11 aligned_alloc() and GNU reallocarray() 423963 Error in child thread when CLONE_PIDFD is used 426148 crash with "impossible happened" when running BPF CO-RE programs 429375 PPC ISA 3.1 support is missing, part 9 431157 PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2 431306 Update demangler to support Rust v0 name mangling 432387 s390x: z15 instructions support 433437 FreeBSD support, part 1 433438 FreeBSD support, part 2 433439 FreeBSD support, part 3 433469 FreeBSD support, part 4 433473 FreeBSD support, part 5 433477 FreeBSD support, part 6 433479 FreeBSD support, part 7 433504 FreeBSD support, part 8 433506 FreeBSD support, part 9 433507 FreeBSD support, part 10 433508 FreeBSD support, part 11 433510 FreeBSD support, part 12 433801 PPC ISA 3.1 support is missing, part 10 (ISA 3.1 support complete) 433863 s390x: memcheck/tests/s390x/{cds,cs,csg} failures 434296 s390x: False-positive memcheck diagnostics from vector string instructions 434840 PPC64 darn instruction not supported 435665 PPC ISA 3.0 copy, paste, cpabort instructions are not supported 435908 valgrind tries to fetch from deubginfod for files which already have debug information 438871 unhandled instruction bytes: 0xF3 0x49 0xF 0x6F 0x9C 0x24 0x60 0x2 439046 valgrind is unusably large when linked with lld 439090 Implement close_range(2) 439326 Valgrind 3.17.0 won't compile with Intel 2021 oneAPI compilers 439590 glibc-2.34 breaks suppressions against obj:*/lib*/libc-2.*so* 440670 unhandled ppc64le-linux syscall: 252 statfs64 and 253 fstatfs64 440906 Fix impossible constraint issue in P10 testcase. 441512 Remove a unneeded / unnecessary prefix check. 441534 Update the expected output for test_isa_3_1_VRT. 442061 very slow execution under Fedora 34 (readdwarf3) 443031 Gcc -many change requires explicit .machine directives 443033 Add support for the ISA 3.0 mcrxrx instruction 443034 Sraw, srawi, srad, sradi, mfs 443178 Powerpc, test jm-mfspr expected output needs to be updated. 443179 Need new test for the lxvx and stxvx instructions on ISA 2.07 and ISA 3.0 systems. 443180 The subnormal test and the ISA 3.0 test generate compiler warnings 443314 In the latest GIT version, Valgrind with "--trace-flags" crashes at "al" register 443605 Don't call final_tidyup (__libc_freeres) on FatalSignal 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 below. (3.18.0.RC1: 12 Oct 2021) (3.18.0: 15 Oct 2021) MD5SUM: de56a5532b0c81781db677ca712c585a valgrind-3.18.1.tar.bz2 SHA1SUM: 0a694a8d0c2152978bf64b67ad0b3dd972bbeb54 valgrind-3.18.1.tar.bz2 |
|
From: Mark W. <ma...@kl...> - 2021-11-17 23:18:10
|
Hi Paul, On Wed, Nov 17, 2021 at 11:13:00PM +0100, Paul Floyd wrote: > I got this from my first attempt at a push: > > paulf> git push > Enumerating objects: 9, done. > Counting objects: 100% (9/9), done. > Delta compression using up to 4 threads > Compressing objects: 100% (5/5), done. > Writing objects: 100% (5/5), 481 bytes | 481.00 KiB/s, done. > Total 5 (delta 4), reused 0 (delta 0), pack-reused 0 > remote: error: unable to unlink old 'docs/manual/mc-manual.html': Permission > denied > To ssh://sourceware.org/git/valgrind-htdocs.git > 59967f7..e2d0a33 main -> main > [...] > A problem with the git hooks? Yes, sorry, it didn't set the file permissions correctly. It should now make sure all files can be updated by someone in the valgrind group. Cheers, Mark |