|
From: Mark W. <ma...@kl...> - 2022-10-19 23:52:56
|
Greetings. A first release candidate for 3.20.0 is available at https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 (md5 = 981b9276536843090700c1268549186e) Please give it a try on platforms that are important for you. If no serious issues are reported, the 3.20.0 final release will happen on 22 October. |
|
From: Paul F. <pj...@wa...> - 2022-10-20 19:16:16
|
On 10/20/22 01:52, Mark Wielaard wrote: > Greetings. > > A first release candidate for 3.20.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 > (md5 = 981b9276536843090700c1268549186e) > > Please give it a try on platforms that are important for you. If no > serious issues are reported, the 3.20.0 final release will happen on > 22 October. FreeBSD 13.1 LGTM One slight oddity. I had a couple of failures (the ann1 and ann2 callgrind and cachegrind tests) after doing autogen && configure && make && make check && make regtest That seems to be because the timestamp of cgout-test is older than a.c causing +@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ +@ Source file 'a.c' is more recent than input file '../../cachegrind/tests/cgout-test'. +@ Annotations may not be correct. +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ + A+ Paul |
|
From: Paul F. <pj...@wa...> - 2022-10-21 06:17:12
|
On 10/20/22 01:52, Mark Wielaard wrote: > Greetings. > > A first release candidate for 3.20.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 > (md5 = 981b9276536843090700c1268549186e) > > Please give it a try on platforms that are important for you. If no > serious issues are reported, the 3.20.0 final release will happen on > 22 October. Hi And finally, macOS. On my old macbook (10.7) there was a build error that I corrected last night. Otherwise no real change since 3.19 - two regtests fail to build - 236 regtest failures out of 671 with 1 hang A+ Paul |
|
From: Mathieu M. <ma...@de...> - 2022-10-21 06:20:22
|
Hi there, On Thu, Oct 20, 2022 at 9:16 PM Paul Floyd <pj...@wa...> wrote: > > > > On 10/20/22 01:52, Mark Wielaard wrote: > > Greetings. > > > > A first release candidate for 3.20.0 is available at > > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 > > (md5 = 981b9276536843090700c1268549186e) > > > > Please give it a try on platforms that are important for you. If no > > serious issues are reported, the 3.20.0 final release will happen on > > 22 October. > Could someone apply the following patch: sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am ref: https://bugs.kde.org/show_bug.cgi?id=456200 Thanks & Regards |
|
From: Philippe W. <phi...@sk...> - 2022-10-22 12:58:48
|
I have started running valgrind on valgrind (outer/inner setup). Results should be available tomorrow evening or so ... For the first few tests, seems ok. Just one strange thing: The outer valgrind crashes on the below test (while the native run of this test is ok). (this is on gcc farm gcc186). Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, but would not be ok when the same valgrind runs as an outer. In any case, this is not blocking. More complete results will follow ... Philippe cachegrind/tests/x86/fpu-28-108.outer.log:10:valgrind: Fatal error at startup: a function redirection cachegrind/tests/x86/fpu-28-108.outer.log:11:valgrind: which is mandatory for this platform-tool combination cachegrind/tests/x86/fpu-28-108.outer.log:12:valgrind: cannot be set up. Details of the redirection are: cachegrind/tests/x86/fpu-28-108.outer.log:13:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:14:valgrind: A must-be-redirected function cachegrind/tests/x86/fpu-28-108.outer.log:15:valgrind: whose name matches the pattern: strlen cachegrind/tests/x86/fpu-28-108.outer.log:16:valgrind: in an object with soname matching: ld-linux.so.2 cachegrind/tests/x86/fpu-28-108.outer.log:17:valgrind: was not found whilst processing cachegrind/tests/x86/fpu-28-108.outer.log:18:valgrind: symbols from the object with soname: ld-linux.so.2 cachegrind/tests/x86/fpu-28-108.outer.log:19:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:20:valgrind: Possible fixes: (1, short term): install glibc's debuginfo cachegrind/tests/x86/fpu-28-108.outer.log:21:valgrind: package on this machine. (2, longer term): ask the packagers cachegrind/tests/x86/fpu-28-108.outer.log:22:valgrind: for your Linux distribution to please in future ship a non- cachegrind/tests/x86/fpu-28-108.outer.log:23:valgrind: stripped ld.so (or whatever the dynamic linker .so is called) cachegrind/tests/x86/fpu-28-108.outer.log:24:valgrind: that exports the above-named function using the standard cachegrind/tests/x86/fpu-28-108.outer.log:25:valgrind: calling conventions for this platform. The package you need cachegrind/tests/x86/fpu-28-108.outer.log:26:valgrind: to install for fix (1) is called cachegrind/tests/x86/fpu-28-108.outer.log:27:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:28:valgrind: On Debian, Ubuntu: libc6-dbg cachegrind/tests/x86/fpu-28-108.outer.log:29:valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo cachegrind/tests/x86/fpu-28-108.outer.log:30:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:31:valgrind: Note that if you are debugging a 32 bit process on a cachegrind/tests/x86/fpu-28-108.outer.log:32:valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo cachegrind/tests/x86/fpu-28-108.outer.log:33:valgrind: package (e.g. libc6-dbg:i386). cachegrind/tests/x86/fpu-28-108.outer.log:34:valgrind: cachegrind/tests/x86/fpu-28-108.outer.log:35:valgrind: Cannot continue -- exiting now. Sorry. On Thu, 2022-10-20 at 01:52 +0200, Mark Wielaard wrote: > Greetings. > > A first release candidate for 3.20.0 is available at > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2 > (md5 = 981b9276536843090700c1268549186e) > > Please give it a try on platforms that are important for you. If no > serious issues are reported, the 3.20.0 final release will happen on > 22 October. > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Mark W. <ma...@kl...> - 2022-10-22 15:36:12
|
Hi,
On Thu, Oct 20, 2022 at 01:25:44PM -0700, Carl Love wrote:
> The only issue noted, as discussed on #valgrind-dev channel, is the
> addition of four post errors for the 3.20RC tree on all of the Power
> platforms. Specifically:
>
> cachegrind/tests/ann1 (post)
> cachegrind/tests/ann2 (post)
> callgrind/tests/ann1 (post)
> callgrind/tests/ann2 (post)
>
> The output from cachegrind/tests/ann1.post.diff is:
>
> --- ann1.post.exp 2021-01-21 09:09:33.000000000 -0600
> +++ ann1.post.out 2022-10-20 14:07:33.272141328 -0500
> @@ -33,6 +33,13 @@
> --------------------------------------------------------------------
> -----------
> -
> -- Auto-annotated source: a.c
> --------------------------------------------------------------------
> -----------
> -
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
> WARNING @@
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@ Source file 'a.c' is more recent than input file 'cgout-test'.
> +@ Annotations may not be correct.
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +
> Ir I1mr ILmr
>
> 2 0 0 int main(void) {
>
> As discussed on the #valgrind-dev channel, this appears to be a
> timestamp issue. Doing a touch * in directory cachegrind/tests seems
> to fix all four post errors.
>
> No other issues were noted. I would vote to do the touch * command and
> go ahead with the release.
I added the touch to the testcases as attached. That makes sure the
cgout-test file is always newer.
Cheers,
Mark
|
|
From: Mark W. <ma...@kl...> - 2022-10-22 22:11:41
|
Hi Philippe, On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote: > I have started running valgrind on valgrind (outer/inner setup). > Results should be available tomorrow evening or so ... > For the first few tests, seems ok. > > Just one strange thing: > The outer valgrind crashes on the below test (while the native run of this test is ok). > (this is on gcc farm gcc186). > > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, > but would not be ok when the same valgrind runs as an outer. > In any case, this is not blocking. > > More complete results will follow ... Thanks. I have no theory for the outer valgrind crash. But it doesn't seem blocking indeed. I am also still running some tests. Please let me know of further results. And do the actual release on Monday (unless some regression blocker turns up). Cheers, Mark |
|
From: Philippe W. <phi...@sk...> - 2022-10-23 14:19:05
|
On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote: > Hi Philippe, > > On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote: > > I have started running valgrind on valgrind (outer/inner setup). > > Results should be available tomorrow evening or so ... > > For the first few tests, seems ok. > > > > Just one strange thing: > > The outer valgrind crashes on the below test (while the native run of this test is ok). > > (this is on gcc farm gcc186). > > > > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode, > > but would not be ok when the same valgrind runs as an outer. > > In any case, this is not blocking. > > > > More complete results will follow ... > > Thanks. I have no theory for the outer valgrind crash. But it doesn't > seem blocking indeed. I am also still running some tests. Please let > me know of further results. And do the actual release on Monday > (unless some regression blocker turns up). > > Cheers, > > Mark > For the crash of the outer valgrind: there is in fact some debug info really missing on gcc186 (also for the inner) for the 32 bits version. I have looked at the results of this outer/inner setup and found nothing that seems problematic. Note that analysis the outer logs is always painful, as the outer reports as "bugs" the fact the inner uses e.g. some invalid memory because the guest program run by the inner is designed to test the usage of such invalid memory. Thanks Philippe |
|
From: Mark W. <ma...@kl...> - 2022-10-24 19:55:11
|
Hi Mathieu, On Fri, Oct 21, 2022 at 08:20:01AM +0200, Mathieu Malaterre wrote: > Could someone apply the following patch: > > sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am > > ref: > https://bugs.kde.org/show_bug.cgi?id=456200 Sorry this didn't make the release. I would have to retest the build on a arm machine without neon and I didn't immediately have one. But this change is probably correct if we want to make valgrind work on systems that don't have neon. Given that Debian uses this, they probably support such arm machines. Cheers, Mark |
|
From: Mathieu M. <ma...@de...> - 2022-10-25 07:04:34
|
Hi Mark ! On Mon, Oct 24, 2022 at 10:01 PM Mark Wielaard <ma...@kl...> wrote: > > Hi Mathieu, > > On Fri, Oct 21, 2022 at 08:20:01AM +0200, Mathieu Malaterre wrote: > > Could someone apply the following patch: > > > > sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am > > > > ref: > > https://bugs.kde.org/show_bug.cgi?id=456200 > > Sorry this didn't make the release. I would have to retest the build > on a arm machine without neon and I didn't immediately have one. But > this change is probably correct if we want to make valgrind work on > systems that don't have neon. Given that Debian uses this, they > probably support such arm machines. Just FYI, this patch is in use in Debian/valgrind package since July 2022 (armhf arch). |