You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark W. <ma...@kl...> - 2021-03-17 17:00:17
|
Hi Carl,
On Wed, 2021-03-17 at 09:36 -0700, Carl Love wrote:
> On Wed, 2021-03-17 at 13:08 +0100, Mark Wielaard wrote:
> The testing on the ISA 3.1 because the file
> none/tests/ppc64/isa_3_1_register_defines.h is missing from RC2. I
> checked and it is also missing from RC1. The file does exist in the
> Vaglrind git tree. Not sure why it is missing in the RCs. Not sure
> why I didn't pick that up with the previous RC1 testing. Sorry about
> that.
Oops. It looks like that was missed because it isn't used unless
building for ISA3.1. I committed the following to make sure it will be
in the final release tarball:
commit 8616808ab3cc691699bd1f733eb9b3106a1a6256
Author: Mark Wielaard <ma...@kl...>
Date: Wed Mar 17 17:56:07 2021 +0100
Add isa_3_1_register_defines.h to Makefile.am noinst_HEADERS
Make sure isa_3_1_register_defines.h ends up in the dist tarball.
diff --git a/none/tests/ppc64/Makefile.am b/none/tests/ppc64/Makefile.am
index 23a22d922..38a3dc483 100644
--- a/none/tests/ppc64/Makefile.am
+++ b/none/tests/ppc64/Makefile.am
@@ -3,7 +3,7 @@ include $(top_srcdir)/Makefile.tool-tests.am
dist_noinst_SCRIPTS = filter_stderr
-noinst_HEADERS = ppc64_helpers.h isa_3_1_helpers.h
+noinst_HEADERS = ppc64_helpers.h isa_3_1_helpers.h isa_3_1_register_defines.h
EXTRA_DIST = \
jm-int.stderr.exp jm-int.stdout.exp jm-int.vgtest jm-int.stdout.exp-LE \
Thanks,
Mark
|
|
From: Mark W. <ma...@kl...> - 2021-03-17 12:08:51
|
Greetings. A second release candidate for 3.17.0 is available at https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC2.tar.bz2 (md5 = 5dcf7c42635e19b074714c53f3a57580) Thanks for the testing of RC1. The changes between RC1 and RC2 are minimal: - debuginfod-check.pl is now included to fix make regtest. - libmpiwrap.c now compiles whether or not openmpi has MPI1 support. - Two fixes for make check on Darwin/MacOS X are included. Please give it a try on platforms that are important for you. If no serious issues are reported, the 3.17.0 final release will happen on 19 March, that is, on Friday of this week. |
|
From: Mark W. <ma...@kl...> - 2021-03-16 23:29:09
|
Hi Paul, On Tue, Mar 16, 2021 at 09:07:56PM +0100, Paul Floyd wrote: > > On 3/15/21 1:33 PM, Mark Wielaard wrote: > > Greetings. > > > > A first release candidate for 3.17.0 is available at > > https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC1.tar.bz2 > > (md5 = 9df201b3461a1709993ffc50d0920bd7) > > > > Please give it a try on platforms that are important for you. If no > > serious issues are reported, the 3.17.0 final release will happen on 19 > > March, that is, on Friday of this week. > > Please let me know if you'd prefer me to push the two small changes in the > tests described below now, or to wait after 3.17 ships. I think it would be good to get these small fixes in and do an RC2 (including the mpi build fix) to make sure things build out of the box on more setups. > On OS X 10.7.5 (Darwin 11.4.2), I've tried a bit harder than usual to get > everything to build at least. I still have a lot of compiler problems. The > last available XCode for this platform is too old for the current Valgrind > source (it doen't support some of the asm opcodes). So I've been using > macports clang (version 9 for the C code and 11 for the C++). > > There's a small issue building dhat/tests/copy.c, it just needs a '|| > defined(VGO_darwin). I assume because darwin, like solaris, doesn't have mempcpy. That should be fine. > none/tests/tls isn't building - a link error with the TLS variable "__thread > int global;". Needs more investigation. That doesn't ring a bell. > ./tests/arm64_features.c doesn't compile: > > arm64_features.c:4:10: fatal error: 'sys/auxv.h' file not found > #include <sys/auxv.h> > ^~~~~~~~~~~~ > Hmmm, that is for getauxval. That probably isn't available on Darwin. I don't immediately know how to replace that. Cheers, Mark |
|
From: Paul F. <pj...@wa...> - 2021-03-16 20:08:14
|
On 3/15/21 1:33 PM, Mark Wielaard wrote: > Greetings. > > A first release candidate for 3.17.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC1.tar.bz2 > (md5 = 9df201b3461a1709993ffc50d0920bd7) > > Please give it a try on platforms that are important for you. If no > serious issues are reported, the 3.17.0 final release will happen on 19 > March, that is, on Friday of this week. Hi Please let me know if you'd prefer me to push the two small changes in the tests described below now, or to wait after 3.17 ships. On OS X 10.7.5 (Darwin 11.4.2), I've tried a bit harder than usual to get everything to build at least. I still have a lot of compiler problems. The last available XCode for this platform is too old for the current Valgrind source (it doen't support some of the asm opcodes). So I've been using macports clang (version 9 for the C code and 11 for the C++). There's a small issue building dhat/tests/copy.c, it just needs a '|| defined(VGO_darwin). none/tests/tls isn't building - a link error with the TLS variable "__thread int global;". Needs more investigation. ./tests/arm64_features.c doesn't compile: arm64_features.c:4:10: fatal error: 'sys/auxv.h' file not found #include <sys/auxv.h> ^~~~~~~~~~~~ I'm running the regression tests. They are very slow so I might net get them tonight. A+ Paul |
|
From: Mark W. <ma...@kl...> - 2021-03-16 12:19:47
|
Hi Carl, On Mon, 2021-03-15 at 11:33 -0700, Carl Love wrote: > Will Schmidt posted an email with regards to the build issue: > > I think so.. we ran into a similar issue late last year, which I > think > we had determined was due to the MPI packages in the > environment. > The patch in comment #3 of this bugzilla helped us at that time. > https://bugs.kde.org/show_bug.cgi?id=401416 Thanks. That explains why I am not seeing it on Fedora, but you are seeing it on Ubuntu. OpenMPI4 disables MPI1 support by default, but fedora still enables it (for now). > I applied the MPI patch to the mainline git tree on the system where > I had the compile error. It fixed the compile issue. I applied the > patch to another system which didn't have the compile issue. The patch > did not break anything. As far as I can tell, the MPI patch is fine. It seems fine if MPI1 is removed. But I am not 100% sure if it is fine when you still have MPI1 support. I'll try and test it a bit. > I pulled the mainline git tree and retested on Power 8LE, Power 8BE, > Power 9, and prototype hardware. The regression tests all look fine > with the above mentioned MPI fix where needed. Nice. Thanks, Mark |
|
From: Mark W. <ma...@kl...> - 2021-03-15 16:14:25
|
Hi Carl, On Mon, 2021-03-15 at 09:05 -0700, Carl Love wrote: > I am seeing issues on various power platforms. > > Power 8 BE > > gcc --version > gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) > > more /etc/os-release > NAME=Fedora > VERSION="27 (Server Edition)" > ID=fedora > VERSION_ID=27 > PRETTY_NAME="Fedora 27 (Server Edition)" > ANSI_COLOR="0;34" > CPE_NAME="cpe:/o:fedoraproject:fedora:27" > HOME_URL="https://fedoraproject.org/" > SUPPORT_URL=" > https://fedoraproject.org/wiki/Communicating_and_getting_help" > BUG_REPORT_URL="https://bugzilla.redhat.com/" > REDHAT_BUGZILLA_PRODUCT="Fedora" > REDHAT_BUGZILLA_PRODUCT_VERSION=27 > REDHAT_SUPPORT_PRODUCT="Fedora" > REDHAT_SUPPORT_PRODUCT_VERSION=27 > PRIVACY_POLICY_URL=" > https://fedoraproject.org/wiki/Legal:PrivacyPolicy" > VARIANT="Server Edition" > VARIANT_ID=server > > I am getting the following error while running make regtest > > leak-pool-4: valgrind ./leak-pool 4 > leak-pool-5: valgrind ./leak-pool 5 > leak-segv-jmp: (skipping, prereq failed: ! ../../tests/os_test > darwin && ! ../../tests/arch_test mips32 && ! > ../../tests/arch_test > ppc64) > leak-tree: valgrind -q --leak-check=full --leak- > resolution=high ./leak-tree > leak_cpp_interior: valgrind --leak-check=summary --leak-check- > heuristics=multipleinheritance,stdstring,newarray,length64 -- > suppressions=libstdc++.supp ./leak_cpp_interior > -- Running tests in memcheck/tests/linux ------------------------ > -- > ---- > brk: valgrind ./brk > capget: valgrind ./capget > /bin/sh: ./debuginfod-check.pl: No such file or directory > prereq returned 127: ./debuginfod-check.pl > ...checking makefile consistency > ...checking header files and include directives > make: *** [Makefile:1367: regtest] Error 1 Unfortunately debuginfod-check.pl was missing. I just added it: https://sourceware.org/git/?p=valgrind.git;a=commit;h=3751e963fab1d644508a9c25b0f147ad609d5dff > I see the same error on a Power 9 > > more /etc/os-release > NAME="Ubuntu" > VERSION="18.04.5 LTS (Bionic Beaver)" > ID=ubuntu > ID_LIKE=debian > PRETTY_NAME="Ubuntu 18.04.5 LTS" > VERSION_ID="18.04" > HOME_URL="https://www.ubuntu.com/" > SUPPORT_URL="https://help.ubuntu.com/" > BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" > PRIVACY_POLICY_URL=" > https://www.ubuntu.com/legal/terms-and-policies/privacy-poli > cy" > VERSION_CODENAME=bionic > UBUNTU_CODENAME=bionic > > > I am seeing compilation issues on Power 8LE > > gcc --version > gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 > > NAME="Ubuntu" > VERSION="20.04.1 LTS (Focal Fossa)" > ID=ubuntu > ID_LIKE=debian > PRETTY_NAME="Ubuntu 20.04.1 LTS" > VERSION_ID="20.04" > HOME_URL="https://www.ubuntu.com/" > SUPPORT_URL="https://help.ubuntu.com/" > BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" > PRIVACY_POLICY_URL=" > https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" > VERSION_CODENAME=focal > UBUNTU_CODENAME=focal > > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:1112:24: > note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 1112 | # define MPI_UB > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_UB, MPI_Type_create_resized); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:281:19: note: in expansion of macro ‘MPI_UB’ > 281 | else if (ty == MPI_UB) fprintf(f,"UB"); > | ^~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:1113:24: > note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 1113 | # define MPI_LB > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_LB, MPI_Type_create_resized); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:282:19: note: in expansion of macro ‘MPI_LB’ > 282 | else if (ty == MPI_LB) fprintf(f,"LB"); > | ^~~~~~ > libmpiwrap.c: In function ‘showCombiner’: > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:743:46: note: > in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 743 | # define MPI_COMBINER_HVECTOR_INTEGER > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HVECTOR_INTEGER, > MPI_COMBINER_HVECTOR); > | ^~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:354:12: note: in expansion of macro > ‘MPI_COMBINER_HVECTOR_INTEGER’ > 354 | case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f, > "HVECTOR_INTEGER"); break; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:743:46: note: > in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 743 | # define MPI_COMBINER_HVECTOR_INTEGER > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HVECTOR_INTEGER, > MPI_COMBINER_HVECTOR); > | ^~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:354:12: note: in expansion of macro > ‘MPI_COMBINER_HVECTOR_INTEGER’ > 354 | case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f, > "HVECTOR_INTEGER"); break; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:354:40: error: expected expression before ‘:’ token > 354 | case MPI_COMBINER_HVECTOR_INTEGER: fprintf(f, > "HVECTOR_INTEGER"); break; > | ^ > In file included from libmpiwrap.c:116: > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:744:47: note: > in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 744 | # define MPI_COMBINER_HINDEXED_INTEGER > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HINDEXED_INTEGER, > MPI_COMBINER_HINDEXED); > | ^~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:359:12: note: in expansion of macro > ‘MPI_COMBINER_HINDEXED_INTEGER’ > 359 | case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f, > "HINDEXED_INTEGER"); break; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:744:47: note: > in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 744 | # define MPI_COMBINER_HINDEXED_INTEGER > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_HINDEXED_INTEGER, > MPI_COMBINER_HINDEXED); > | ^~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:359:12: note: in expansion of macro > ‘MPI_COMBINER_HINDEXED_INTEGER’ > 359 | case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f, > "HINDEXED_INTEGER"); break; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:359:41: error: expected expression before ‘:’ token > 359 | case MPI_COMBINER_HINDEXED_INTEGER: fprintf(f, > "HINDEXED_INTEGER"); break; > | ^ > In file included from libmpiwrap.c:116: > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:745:45: note: > in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 745 | # define MPI_COMBINER_STRUCT_INTEGER > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_STRUCT_INTEGER, > MPI_COMBINER_STRUCT); > | ^~~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:366:12: note: in expansion of macro > ‘MPI_COMBINER_STRUCT_INTEGER’ > 366 | case MPI_COMBINER_STRUCT_INTEGER: fprintf(f, > "STRUCT_INTEGER"); break; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:745:45: note: > in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 745 | # define MPI_COMBINER_STRUCT_INTEGER > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_COMBINER_STRUCT_INTEGER, > MPI_COMBINER_STRUCT); > | ^~~~~~~~~~~~~~ > ~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:366:12: note: in expansion of macro > ‘MPI_COMBINER_STRUCT_INTEGER’ > 366 | case MPI_COMBINER_STRUCT_INTEGER: fprintf(f, > "STRUCT_INTEGER"); break; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:366:39: error: expected expression before ‘:’ token > 366 | case MPI_COMBINER_STRUCT_INTEGER: fprintf(f, > "STRUCT_INTEGER"); break; > | ^ > libmpiwrap.c: In function ‘extentOfTy’: > libmpiwrap.c:462:8: warning: implicit declaration of function > ‘PMPI_Type_extent’; did you mean ‘MPI_Type_extent’? [-Wimplicit- > function-declaration] > 462 | r = PMPI_Type_extent(ty, &n); > | ^~~~~~~~~~~~~~~~ > | MPI_Type_extent > In file included from libmpiwrap.c:116: > libmpiwrap.c: In function ‘walk_type’: > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:322:57: > error: expected expression before ‘_Static_assert’ > 322 | #define THIS_SYMBOL_WAS_REMOVED_IN_MPI30(func, newfunc) > _Static_assert(0, #func " was removed in MPI-3.0. Use " #newfunc " > instead.") > | ^~ > ~~~~~~~~~~~~ > /usr/lib/powerpc64le-linux-gnu/openmpi/include/mpi.h:1113:24: > note: in expansion of macro ‘THIS_SYMBOL_WAS_REMOVED_IN_MPI30’ > 1113 | # define MPI_LB > THIS_SYMBOL_WAS_REMOVED_IN_MPI30(MPI_LB, MPI_Type_create_resized); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > libmpiwrap.c:736:17: note: in expansion of macro ‘MPI_LB’ > 736 | if (ty == MPI_LB || ty == MPI_UB) > | ^~~~~~ > make[2]: *** [Makefile:716: libmpiwrap_ppc64le_linux_so- > libmpiwrap.o] Error 1 > make[2]: Leaving directory '/home/carll/Valgrind/valgrind- > 3.17.0.RC1/mpi' > make[1]: *** [Makefile:855: check-recursive] Error 1 > make[1]: Leaving directory '/home/carll/Valgrind/valgrind- > 3.17.0.RC1' > make: *** [Makefile:1149: check] Error 2 > > I will dig into this a bit more and see if I can find a fix for the > error. I will let you know. I just did a build on Fedora, and I am not seeing these issues. It might depend on the version of openmpi installed I assume. https://koji.fedoraproject.org/koji/buildinfo?buildID=1723501 Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2021-03-15 12:34:18
|
Greetings. A first release candidate for 3.17.0 is available at https://sourceware.org/pub/valgrind/valgrind-3.17.0.RC1.tar.bz2 (md5 = 9df201b3461a1709993ffc50d0920bd7) Please give it a try on platforms that are important for you. If no serious issues are reported, the 3.17.0 final release will happen on 19 March, that is, on Friday of this week. |
|
From: Tom H. <to...@co...> - 2021-02-06 10:15:15
|
On 06/02/2021 07:59, Muhui Jiang wrote: > I am new to Valgrind and have some questions about the principles of > Valgrind. > > According to the manual, > https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes > <https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes> > "Your program is then run on a synthetic CPU provided by the Valgrind core." > "Valgrind simulates every single instruction your program executes" > > I am curious that as a binary instrumentation framework, why Valgrind > needs to simulate the CPU and instruction execution. It seems that the > host and guest architecture must be the same due to the multiple > syscalls. If so, why not use the host CPU to run the translated binary > directly instead of simulation? Simulated instruction execution might be > different from the execution on physical devices. It does run on the native CPU because valfrind is a JIT that converts the original instructions to an internal form which it analyses and instruments and then converts the instrumented code back into native code which is then run on the real processor. But from the point of view of the program it is running on valgrind's emulated CPU and can only use those instructions and features which valgrind knows how to emulate. > The other question is that what part is simulated for a CPU except for > the instruction execution. Are the memory model, cache, and registers > all simulated/emulated. Any suggestions and comments are welcome. Many > Thanks The cache is simulated in parallel for cachegrind/callgrind in order to generate estimated statistics for cache hit/misses. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Muhui J. <jia...@gm...> - 2021-02-06 07:59:53
|
Hi all I am new to Valgrind and have some questions about the principles of Valgrind. According to the manual, https://valgrind.org/docs/manual/manual-core.html#manual-core.whatdoes "Your program is then run on a synthetic CPU provided by the Valgrind core." "Valgrind simulates every single instruction your program executes" I am curious that as a binary instrumentation framework, why Valgrind needs to simulate the CPU and instruction execution. It seems that the host and guest architecture must be the same due to the multiple syscalls. If so, why not use the host CPU to run the translated binary directly instead of simulation? Simulated instruction execution might be different from the execution on physical devices. The other question is that what part is simulated for a CPU except for the instruction execution. Are the memory model, cache, and registers all simulated/emulated. Any suggestions and comments are welcome. Many Thanks Regards Muhui |
|
From: Tom H. <to...@co...> - 2021-02-04 11:15:01
|
On 04/02/2021 10:57, Matthias Apitz wrote:
> El día jueves, febrero 04, 2021 a las 09:48:23a. m. +0000, Tom Hughes escribió:
>
>> On 04/02/2021 09:26, Matthias Apitz wrote:
>>
>>> At the moment we use the following "trick": the librarian runs in
>>> parallel to the client on the desktop a second window with a "tail -f ..."
>>> on valgrinds log file (STDOUT) and the full screen is recorded with
>>> Microsoft teams functionality. So we can use the timestamps in the log
>>> to go to the replay of the recording and can see what the user did
>>> exactly, which data was entered and which button pressed etc.
>>>
>>> Are there other ideas to bring together the valgrind log and the usage
>>> of the application?
>>
>> You could instrument the request processing logic to log details
>> of the request if any errors are detected while processing it, so
>> something like:
>>
>> #include "valgrind/valgrind.h"
>>
>> return_type process_request(...)
>> {
>> int errors = VALGRIND_COUNT_ERRORS;
>>
>> // process request as normal
>>
>> if (VALGRIND_COUNT_ERRORS > errors)
>> {
>> VALGRIND_PRINTF("Saw errors processing request %s", request_name);
>> }
>> }
>>
>> Obviously you can change it to log whatever details you want.
>
> Thanks, this looks like a good plan!
>
> The above are macros, are there additional shared libs to link with our
> process?
No - the valgrind client directives work by generating a special
sequence of assembly language instructions that is spotted by the
valgrind virtual machine and causes valgrind to generate a call to
an internal routine.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Matthias A. <gu...@un...> - 2021-02-04 10:57:38
|
El día jueves, febrero 04, 2021 a las 09:48:23a. m. +0000, Tom Hughes escribió:
> On 04/02/2021 09:26, Matthias Apitz wrote:
>
> > At the moment we use the following "trick": the librarian runs in
> > parallel to the client on the desktop a second window with a "tail -f ..."
> > on valgrinds log file (STDOUT) and the full screen is recorded with
> > Microsoft teams functionality. So we can use the timestamps in the log
> > to go to the replay of the recording and can see what the user did
> > exactly, which data was entered and which button pressed etc.
> >
> > Are there other ideas to bring together the valgrind log and the usage
> > of the application?
>
> You could instrument the request processing logic to log details
> of the request if any errors are detected while processing it, so
> something like:
>
> #include "valgrind/valgrind.h"
>
> return_type process_request(...)
> {
> int errors = VALGRIND_COUNT_ERRORS;
>
> // process request as normal
>
> if (VALGRIND_COUNT_ERRORS > errors)
> {
> VALGRIND_PRINTF("Saw errors processing request %s", request_name);
> }
> }
>
> Obviously you can change it to log whatever details you want.
Thanks, this looks like a good plan!
The above are macros, are there additional shared libs to link with our
process?
>
> The only issue might be that if the code is multithreaded and can
> process multiple requests in parallel then you won't know which
> thread the errors came from.
No, they're singlethreaded. A master daemon forks for any connecting
client a new server proc.
matthias
--
Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
|
|
From: Tom H. <to...@co...> - 2021-02-04 09:48:54
|
On 04/02/2021 09:26, Matthias Apitz wrote:
> At the moment we use the following "trick": the librarian runs in
> parallel to the client on the desktop a second window with a "tail -f ..."
> on valgrinds log file (STDOUT) and the full screen is recorded with
> Microsoft teams functionality. So we can use the timestamps in the log
> to go to the replay of the recording and can see what the user did
> exactly, which data was entered and which button pressed etc.
>
> Are there other ideas to bring together the valgrind log and the usage
> of the application?
You could instrument the request processing logic to log details
of the request if any errors are detected while processing it, so
something like:
#include "valgrind/valgrind.h"
return_type process_request(...)
{
int errors = VALGRIND_COUNT_ERRORS;
// process request as normal
if (VALGRIND_COUNT_ERRORS > errors)
{
VALGRIND_PRINTF("Saw errors processing request %s", request_name);
}
}
Obviously you can change it to log whatever details you want.
The only issue might be that if the code is multithreaded and can
process multiple requests in parallel then you won't know which
thread the errors came from.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Matthias A. <gu...@un...> - 2021-02-04 09:27:10
|
Hello, The following is not fully on-topic because it's more a question related to how to use valgrind in our case. But maybe others have had similar questions or a solution... We have fat application servers, written in C/C++ on top of a DBS (PostgreSQL). These application servers offer the business logic in a Library Management System to application clients, written in Java, and used by the librarian staff of the institutions. Both, server and client, communicate over a TCP/IP protocol, developed for this purpose by us: the librarian works with client, the client sends business oriented commands to the app server, this does its work in the DBS and gives responses to the client. We do valgrinding the server and from time to time valgrind detects a problem, for example usage of not initialized memory access, or jumps based on this, etc. Sometimes it is very difficult to find the exact reason for valgrind's complaint and one has to use a gdb and for this to redo what the server was executing, or better what the librarian did exactly with the client that caused the server to execute this particular piece of code and with which data input. At the moment we use the following "trick": the librarian runs in parallel to the client on the desktop a second window with a "tail -f ..." on valgrinds log file (STDOUT) and the full screen is recorded with Microsoft teams functionality. So we can use the timestamps in the log to go to the replay of the recording and can see what the user did exactly, which data was entered and which button pressed etc. Are there other ideas to bring together the valgrind log and the usage of the application? Thanks for reading this. matthias -- Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub |
|
From: Matthias A. <gu...@un...> - 2021-01-29 00:47:54
|
El día martes, enero 26, 2021 a las 02:40:26p. m. -0800, John Reiser escribió: > > The reason was at the end of debugging that we replaced in some central > > place of the server a function call (due to vg messages about > > overlapping args) > > > > strncpy(dst, src, n); > > > > by > > > > memset(dst, 0, n); > > memmove(dst, src, n); > > > > which is not fully equivalent because strncpy(3) will stop at the first > > \0 byte in src, while memmove(3) will copy n bytes, regardles if they > > are valid bytes in src. As this was in some low level function, it > > generated a mass of the above vg messages. > [[snip]] > > Any thoughts about this? > > You may have a much bigger problem than you realize. Take paper > and pencil; write TEN TIMES (this is not a joke!): > > strncpy(dst, src, n) always over-writes exactly n bytes > (namely dst[0..(n-1)]), regardless of strlen(src). I know this. strncpy(dst, src, n) writes strlen(src) bytes to dst and fills the rest in dst until n with \0 bytes. This is clear but not the point of the problem. The problem is (was) that strncpy(dst, src, n) only reads(!) strlen(src) bytes from src, while memmove(dst, src, n) reads n bytes from src and if n > strlen(src) it reads illegal bytes, raised as an error by valgrind correctly. matthias -- Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ |
|
From: Kunal C. <atk...@gm...> - 2021-01-27 17:32:16
|
++ by using that flag my process is affecting, or there is some thread optimization flags in valgrind so fruit full logs can be generate On Wed, Jan 27, 2021 at 11:00 PM Kunal Chauhan <atk...@gm...> wrote: > Thanks for hint or approach. > but My concern was, my valgrind is displaying 1000 error but I want > valgrind should not stop at error limit . > as I used --error limit option in valgrind my process some threads does > not work or process in not well executing. > > On Wed, Jan 27, 2021 at 9:42 PM Paul Floyd <pj...@wa...> wrote: > >> >> On 1/27/21 4:31 PM, Kunal Chauhan wrote: >> > As you said if valgrind is just a same as my process with some extra >> > messages. But as I facing in valgrind when i used valgrind option >> > like --errorlimit=no then my process some threads are not working . >> > >> > And if my do not use error limit flag valgrind saying 1000 error >> > reached and it will not display more errors , how can i come out of >> > this situation. >> > >> >> I was only referring to segmentation faults. >> >> >> If there are other errors you will have to fix them. Just start at with >> the first one and continue. >> >> >> Regards >> >> Paul >> >> >> > > -- > *Thanks with Regards!* > > *Kunal Chauhan* > *Mob:09813614826* > *Mob:08860397903* > > *E-mail:atk...@gm... <E-mail%3Aa...@gm...>* > > -- *Thanks with Regards!* *Kunal Chauhan* *Mob:09813614826* *Mob:08860397903* *E-mail:atk...@gm... <E-mail%3Aa...@gm...>* |
|
From: Kunal C. <atk...@gm...> - 2021-01-27 17:30:44
|
Thanks for hint or approach. but My concern was, my valgrind is displaying 1000 error but I want valgrind should not stop at error limit . as I used --error limit option in valgrind my process some threads does not work or process in not well executing. On Wed, Jan 27, 2021 at 9:42 PM Paul Floyd <pj...@wa...> wrote: > > On 1/27/21 4:31 PM, Kunal Chauhan wrote: > > As you said if valgrind is just a same as my process with some extra > > messages. But as I facing in valgrind when i used valgrind option > > like --errorlimit=no then my process some threads are not working . > > > > And if my do not use error limit flag valgrind saying 1000 error > > reached and it will not display more errors , how can i come out of > > this situation. > > > > I was only referring to segmentation faults. > > > If there are other errors you will have to fix them. Just start at with > the first one and continue. > > > Regards > > Paul > > > -- *Thanks with Regards!* *Kunal Chauhan* *Mob:09813614826* *Mob:08860397903* *E-mail:atk...@gm... <E-mail%3Aa...@gm...>* |
|
From: Paul F. <pj...@wa...> - 2021-01-27 11:12:38
|
> On 25 Jan 2021, at 11:49, Kunal Chauhan <atk...@gm...> wrote: > > Thanks for clarifications > ++ if the binary is crashed or may be not crashed when it runs with valgrind, but in both case valgrind is able to give the report. ? Hi If your application causes a segmentation fault, the OS will send it a SIGSEGV signal. When it is running inside Valgrind, Valgrind will see whether or not your application has a signal handler. If not it will print a message describing the fault and also instructions as to what you should do in the unlikely event that the cause is a stack overflow in your program’s main thread. In short, Valgrind will do the same as you application would do running outsizde of Valgrind, just with a lot more messages. A+ Paul |
|
From: John R. <jr...@bi...> - 2021-01-26 22:40:52
|
> The reason was at the end of debugging that we replaced in some central
> place of the server a function call (due to vg messages about
> overlapping args)
>
> strncpy(dst, src, n);
>
> by
>
> memset(dst, 0, n);
> memmove(dst, src, n);
>
> which is not fully equivalent because strncpy(3) will stop at the first
> \0 byte in src, while memmove(3) will copy n bytes, regardles if they
> are valid bytes in src. As this was in some low level function, it
> generated a mass of the above vg messages.
[[snip]]
> Any thoughts about this?
You may have a much bigger problem than you realize. Take paper
and pencil; write TEN TIMES (this is not a joke!):
strncpy(dst, src, n) always over-writes exactly n bytes
(namely dst[0..(n-1)]), regardless of strlen(src).
A large fraction of lexical calls to strncpy are incorrect;
the code just happens to work "by accident".
First, if there is any overlap between the intervals dst[0..(n-1)]
and src[0..(n-1)] then the result is undefined. The implementation
of strncpy is allowed to read and write bytes in ANY order: lowest
index first, highest index first, single byte at a time, multiple
bytes at a time, interleaving Read and Write in any order (including
writing into the same byte multiple times, or writing an incorrect
value but correcting it later), etc. Also, all str* functions are
allowed to fetch beyond src[1+ strlen(src)] as long as there can be
no SIGSEGV; and to store into dst[n] and beyond, as long as there is
no change there. So any byte that is within the memory words or
cache lines that cover src[] or dst[] is fair game to be included
in a memory operation of strncpy.
Second, if (strlen(src) < n) then strncpy zeroes the remaining bytes
through dst[n-1].
Third, if (strlen(src) >= n) then dst is not NUL terminated.
Recommendation: search all the source code of all the projects
of your entire team/department/company for strncpy, and fix the bugs.
--
|
|
From: Tom H. <to...@co...> - 2021-01-26 09:50:39
|
On 26/01/2021 09:32, Matthias Apitz wrote:
> So far so good. What would have helped me is that vg could print in its
> replacement functions for memmove(3) ... (vg_replace_strmem.c:1270)
> the provided pointers and other args, and as well part of the src
> buffer. For sure vg knows exactly these values to watch the illegal
> memory access.
If the memory is uninitialised then printing it's contents
shouldn't really be useful as they will have no meaning...
Presumably it was partially initialised in this case but it
sounds like quite an edge case and it's easy enough to add
some custom debugging to your code when it does help in cases
like this. I'm not clear if you just printed everything but
you can conditionalise it to only print the failing case:
if ( VALGRIND_CHECK_MEM_IS_DEFINED( src, n ) )
{
fprintf( stderr, "ERROR: %.*s\n", n, src );
}
if you want to get really clever you can limit it to printing
the valid part:
const char *fail = VALGRIND_CHECK_MEM_IS_DEFINED( src, n );
if ( fail )
{
fprintf( stderr, "ERROR: %.*s\n", fail - src, src );
}
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Matthias A. <gu...@un...> - 2021-01-26 09:32:18
|
Hello, This is with valgrind 3.14.0 compiled and used on SuSE Linux 12 and 15 x86_64. I have had a hart time to nail down the reason for a lot(!) of such vg messages: ==1272== Invalid read of size 8 ==1272== at 0x4C355BF: memmove (vg_replace_strmem.c:1270) ==1272== by 0x64A50D7: zzstrncpy (zzstdc.C:143) ==1272== by 0x67366DE: SqlCharToChar (ec_general.ec:165) ==1272== by 0x675ED84: Para2Host (acq_update.h:59) ==1272== by 0x675FCE7: SQLExistUpdateEntry (ec_acq_update.ec:200) ... ==1272== Address 0x17d80148 is 24 bytes after a block of size 16 in arena "client" The reason was at the end of debugging that we replaced in some central place of the server a function call (due to vg messages about overlapping args) strncpy(dst, src, n); by memset(dst, 0, n); memmove(dst, src, n); which is not fully equivalent because strncpy(3) will stop at the first \0 byte in src, while memmove(3) will copy n bytes, regardles if they are valid bytes in src. As this was in some low level function, it generated a mass of the above vg messages. To debug it, I ended up printing in hex the pointer src, the value of n and the first n bytes of src which finally gave me a clue what was wrong: the number n was some kind of a fixed maximal length for dst and regardless of the provided bytes in src. Fixed by: memset(dst, 0, n); n = strlen(src); memmove(dst, src, n); So far so good. What would have helped me is that vg could print in its replacement functions for memmove(3) ... (vg_replace_strmem.c:1270) the provided pointers and other args, and as well part of the src buffer. For sure vg knows exactly these values to watch the illegal memory access. Any thoughts about this? matthias -- Matthias Apitz, ✉ gu...@un..., http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ |
|
From: Kunal C. <atk...@gm...> - 2021-01-25 10:50:08
|
Thanks for clarifications ++ if the binary is crashed or may be not crashed when it runs with valgrind, but in both case valgrind is able to give the report. ? On Mon, Jan 25, 2021 at 1:28 PM Paul Floyd <pj...@wa...> wrote: > > > > On 24 Jan 2021, at 18:29, Kunal Chauhan <atk...@gm...> > wrote: > > > > Hi paul, > > > > thanks for info, > > 1.Like in trailing mail you said process under completion what do you > mean exactly, > > 2. Also for running a process under valgrind my binary should be strip > or unstrip.? > > > > 3. Memcheck tool where it fits in context of valgrind . > > > (Replying to the list) > > 1. A command like ‘pwd’. You run the command, it prints the working > directory and then it exits. In this example when the pwd process > completes, Valgrind can detect leaks. > 2. Unstripped binaries with debug information are the best. > 3. Valgrind includes several tools, memcheck being the best known of them, > for detecting memory errors. There are also tools for profiling and thread > hazard detection. > > A+ > Paul > > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- *Thanks with Regards!* *Kunal Chauhan* *Mob:09813614826* *Mob:08860397903* *E-mail:atk...@gm... <E-mail%3Aa...@gm...>* |
|
From: Paul F. <pj...@wa...> - 2021-01-25 07:57:23
|
> On 24 Jan 2021, at 18:29, Kunal Chauhan <atk...@gm...> wrote: > > Hi paul, > > thanks for info, > 1.Like in trailing mail you said process under completion what do you mean exactly, > 2. Also for running a process under valgrind my binary should be strip or unstrip.? > > 3. Memcheck tool where it fits in context of valgrind . (Replying to the list) 1. A command like ‘pwd’. You run the command, it prints the working directory and then it exits. In this example when the pwd process completes, Valgrind can detect leaks. 2. Unstripped binaries with debug information are the best. 3. Valgrind includes several tools, memcheck being the best known of them, for detecting memory errors. There are also tools for profiling and thread hazard detection. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2021-01-24 07:06:05
|
On 1/22/21 9:31 PM, Kunal Chauhan wrote: > Hi Team, > > As on my linux board ,one of process showing some run time memory > increase as seen by pmap command. > > So how valgrind can be useful to search such mem leaks in big code. > > Or is there is way to attached valgrind and see where and which > instruction actually causing issue Hi You can't 'attach' Valgrind to a running process. What you need to do is to run the process under Valgrind. If the process normally runs to completion, you can just run it under Valgrind (by default, the memcheck tool will be used, add --leak-check=full and possibly --show-reachable=yes). If the process is running aas a daemon, then your best bet is to run it under Valgrind and then attach gdb to it and use monitor commands to check for leaks. That is documented on the Valgrind web page, here https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-commandhandling . A+ Paul |
|
From: Kunal C. <atk...@gm...> - 2021-01-22 20:31:55
|
Hi Team, As on my linux board ,one of process showing some run time memory increase as seen by pmap command. So how valgrind can be useful to search such mem leaks in big code. Or is there is way to attached valgrind and see where and which instruction actually causing issue |
|
From: Kunal C. <atk...@gm...> - 2021-01-22 20:23:29
|
Hi Team, As I am facing some issue , like it seems one my process on linux board is increasing its size as seen by pmap commands. So how valgrind can be useful to see this type of memleaks , and what approach to follow up. |