|
From: Mark W. <ma...@kl...> - 2021-09-22 13:02:59
|
Hi, I would like to propose we do a valgrind 3.18.0 release next month. There have been various useful changes since 3.17.0 for power10, s390x z15 updates, arm64 v8.2, glibc 2.34 updates (which are really needed, without them things simply break). I have backported most of the above improvements to the Fedora valgrind package (mainly because Fedora 35 has already switched to glibc 2.34), but that contains 25 patches now (where the power10 and z15 backports count as just one, so it is more like 35 patches), which is not ideal. There is also the DWARF reader speedup patch: https://bugs.kde.org/show_bug.cgi?id=442061 which I would really like to see go in because it really helps startup time (especially with distros that use debuginfod, which valgrind now also supports). I propose to do the release on October 15. So we have some time to go over the open bugs and see which really should get resolved before then. Please do respond if you have bugs/patches that really deserve to be resolved before the 3.18.0 release. Cheers, Mark |
|
From: Carl L. <ce...@us...> - 2021-09-22 16:03:44
|
Mark:
Will and I have been working on some PPC patches. These patches
include some fixes for the latest GCC compiler, adding support for a
missing instruction and some basic cleanup. Specifically on PPC the
option -many has changed which requires adding .machine directives and
fixes to the makefile to ensure the correct processor is specified when
compiling the test cases.
We will see if we can get these finished up and committed in the next
week or so. Other than these cleanups/fixes we have no new
functionality.
Carl Love
On Wed, 2021-09-22 at 15:02 +0200, Mark Wielaard wrote:
> Hi,
>
> I would like to propose we do a valgrind 3.18.0 release next month.
> There have been various useful changes since 3.17.0 for power10,
> s390x
> z15 updates, arm64 v8.2, glibc 2.34 updates (which are really needed,
> without them things simply break).
>
> I have backported most of the above improvements to the Fedora
> valgrind
> package (mainly because Fedora 35 has already switched to glibc
> 2.34),
> but that contains 25 patches now (where the power10 and z15 backports
> count as just one, so it is more like 35 patches), which is not
> ideal.
>
> There is also the DWARF reader speedup patch:
> https://bugs.kde.org/show_bug.cgi?id=442061
> which I would really like to see go in because it really helps
> startup
> time (especially with distros that use debuginfod, which valgrind now
> also supports).
>
> I propose to do the release on October 15. So we have some time to go
> over the open bugs and see which really should get resolved before
> then. Please do respond if you have bugs/patches that really deserve
> to
> be resolved before the 3.18.0 release.
>
> Cheers,
>
> Mark
>
>
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Paul F. <pj...@wa...> - 2021-09-23 19:05:42
|
On 9/22/21 1:02 PM, Mark Wielaard wrote: > Hi, > > I would like to propose we do a valgrind 3.18.0 release next month. > There have been various useful changes since 3.17.0 for power10, s390x > z15 updates, arm64 v8.2, glibc 2.34 updates (which are really needed, > without them things simply break). > > I have backported most of the above improvements to the Fedora valgrind > package (mainly because Fedora 35 has already switched to glibc 2.34), > but that contains 25 patches now (where the power10 and z15 backports > count as just one, so it is more like 35 patches), which is not ideal. > > There is also the DWARF reader speedup patch: > https://bugs.kde.org/show_bug.cgi?id=442061 > which I would really like to see go in because it really helps startup > time (especially with distros that use debuginfod, which valgrind now > also supports). > > I propose to do the release on October 15. So we have some time to go > over the open bugs and see which really should get resolved before > then. Please do respond if you have bugs/patches that really deserve to > be resolved before the 3.18.0 release. Hi Mark I have FreeBSD support that I'd like to add. I'll refresh the patches in bugzilla. Not much has changed, but there has been at least one merge conflict since I last generated the patches. A+ Paul |
|
From: Ed M. <em...@fr...> - 2021-09-24 18:46:05
|
On Thu, 23 Sept 2021 at 15:06, Paul Floyd <pj...@wa...> wrote: > > Hi Mark > > I have FreeBSD support that I'd like to add. > > I'll refresh the patches in bugzilla. Not much has changed, but there > has been at least one merge conflict since I last generated the patches. Thank you Paul for pushing this along. Let me know if I can do anything to help. We also have FreeBSD quarterly status updates[1] coming up and it would be great to include this work in a report. I can help put one together. [1] https://github.com/freebsd/freebsd-quarterly |
|
From: Carl L. <ce...@us...> - 2021-10-01 21:55:02
|
Mark: I opened a number of Power PC bugzillas for the various items I was working on. I committed my 13 patch series that fixes all the issues in the bugzillas that I opened yesterday. I verified that the regression test run from last night reported the additional three tests that were added ran. No new issues were reported. I have now closed all of the bugzillas for the issues that I opened. I looked thru the outstanding Valgrind bugs and closed a couple additional bugs that have been fixed. There are two bugs that users have reported on Powerpc that are still open: https://bugs.kde.org/show_bug.cgi?id=420780 https://bugs.kde.org/show_bug.cgi?id=411189 The second one is for the darn instruction support. That support has been committed. I ran the user's test progam and it seems to be fine. Similarly, I ran the test case in the first bug and it too seems to be resolved by a gcc fix from Michael Ellerman. I put a comment in both bugs asking the reporter to verify the issue is fixed on the upstream valgrind code base. If so, they can close the issue. Those are the only two open issues specific to PPC that I am aware of. It looks to me that both issues are fixed. I am not aware of any additional powerpc specific issues in Valgrind at this time. So from the Powerpc perspective, we are ready for the next Valgrind release. Carl Love |
|
From: Mark W. <ma...@kl...> - 2021-10-05 16:16:11
|
Hi Carl, On Fri, 2021-10-01 at 14:54 -0700, Carl Love wrote: > I opened a number of Power PC bugzillas for the various items I was > working on. I committed my 13 patch series that fixes all the issues > in the bugzillas that I opened yesterday. I verified that the > regression test run from last night reported the additional three > tests > that were added ran. No new issues were reported. I have now closed > all of the bugzillas for the issues that I opened. > > I looked thru the outstanding Valgrind bugs and closed a couple > additional bugs that have been fixed. Thanks! > There are two bugs that users have reported on Powerpc that are still > open: > > https://bugs.kde.org/show_bug.cgi?id=420780 > https://bugs.kde.org/show_bug.cgi?id=411189 > > [...] > Those are the only two open issues specific to PPC that I am aware > of. > It looks to me that both issues are fixed. Yes, it looks like both these are good now. > I am not aware of any additional powerpc specific issues in Valgrind at > this time. So from the Powerpc perspective, we are ready for the next > Valgrind release. Great. We still have Paul's freebsd patches to land. But it looks like we are fairly close now. I would like to resolve at least the following bugs: https://bugs.kde.org/show_bug.cgi?id=439090 Implement close_range(2) ("WARNING: unhandled amd64-linux syscall: 436") Which has an initial patch, but probably needs to use the file descriptor tracking. https://bugs.kde.org/show_bug.cgi?id=426148 Valgrind crash with "impossible happened" when running BPF CO-RE programs Which is about an extension of the bpf systemcall for which we currently crash, but we should be able to handle. I still have an odd issue on s390x with the vgdb, for which I have a workaround, but no root cause yet: https://bugs.kde.org/show_bug.cgi?id=441474 And it seems that if we get a fatal signal at an unfortunate place in the guest program and we call __libc_freeres things blow up. We might want to only call __libc_freeres on normal program exit, not after processing a fatal signal. Don't have a small reproducer yet. Please let me know if there are any other pending bugs that would be nice to get resolved before the release. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2021-10-12 13:19:00
|
Hi valgrind hackers, On Wed, 2021-09-22 at 15:02 +0200, Mark Wielaard wrote: > I would like to propose we do a valgrind 3.18.0 release next month. > There have been various useful changes since 3.17.0 for power10, > s390x z15 updates, arm64 v8.2, glibc 2.34 updates (which are really > needed, without them things simply break). I believe things are looking pretty good, the DWARF reader speedups are in, as are the Power PC fixes and the freebsd port, the libiberty demangler has been updated to support Rust v0 mangling. The bug database was cleaned up a bit and various smaller fixes have landed. And as a bonus both make and make check should now have zero compiler warnings (at least on x86_64 with latest gcc 11). There are 4 issue with patches which I like to land today and then do an RC1 release to more general testing: https://bugs.kde.org/show_bug.cgi?id=443605 Don't call final_tidyup (__libc_freeres) on FatalSignal https://bugs.kde.org/show_bug.cgi?id=439090 Implement close_range(2) https://bugs.kde.org/show_bug.cgi?id=426148 Valgrind crash with "impossible happened" when running BPF CO-RE This isn't a full fix, there are still various BPF syscall commands we don't support, but it should help those using bpf under valgrind to report better bug reports about which support is needed (most). https://bugs.kde.org/show_bug.cgi?id=441474 vgdb might eat all memory while waiting for sigstop This is only a workaround for an issue on s390x which I have been unable to track fully down. But it makes sure we don't eat all memory on the machine. We'll stop after we get more than 64 pending signals. There are also still some issues in the testsuite when running against glibc 2.34 and libstdc++ 11.2. I don't think they are critical, but it would be nice if we could clean them up: On x86_64: == 721 tests, 9 stderr failures, 0 stdout failures, 1 stderrB failure, 0 stdoutB failures, 3 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/overlap (stderr) memcheck/tests/supp_unknown (stderr) helgrind/tests/tls_threads (stderr) drd/tests/annotate_barrier (stderr) drd/tests/bar_bad_xml (stderr) drd/tests/pth_barrier_thr_cr (stderr) drd/tests/tc21_pthonce (stderr) drd/tests/thread_name_xml (stderr) massif/tests/deep-D (post) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) - hginfo detects an extra lock, which I don't know how to suppress: Lock ga 0x........ { Address 0x........ is 2440 bytes inside data symbol "_rtld_local" kind mbRec } - leak_cpp_interior detects slightly different leaks, which I believe are inside libstdc++: - possibly lost: x (-x) bytes in 5 (+1) blocks - still reachable: x (+x) bytes in 3 (-1) blocks + possibly lost: x (-x) bytes in 4 (+0) blocks + still reachable: x (+x) bytes in 5 (+0) blocks of which reachable via heuristic: - newarray : x (+x) bytes in 1 (+1) blocks + newarray : x (+x) bytes in 2 (+2) blocks - overlap is a known issue https://bugs.kde.org/show_bug.cgi?id=402833 - supp_unknown doesn't work because we are missing the main frame somehow - tls_threads sched WARNING: pthread stack cache cannot be disabled! This was changed in glibc 2.34, there is a new mechanism. Also helgrind seems to detect a race in pthread_create@* itself which seems odd, bad suppression? - annotate_barrier expects a backtrace in libpthread, but symbols have moved into main libc.so - by 0x........: (within libpthread-?.?.so) + by 0x........: start_thread (in /...libc...) Needs an alternate .exp file? - bar_bad_xml, we expect an unversioned pthread_barrier_init in the xml output, but get a versioned one. <frame> <ip>0x........</ip> <obj>...</obj> - <fn>pthread_barrier_init</fn> + <fn>pthread_barrier_init@*</fn> <dir>...</dir> <file>drd_pthread_intercepts.c</file> Should we just filter out the @* ? - pth_barrier_thr_cr Number of concurrent pthread_barrier_wait() calls exceeds the barrier count Not analyzed yet. - tc21_pthonce same as annotate_barrier - thread_name_xml same as bar_bad_xml but now for pthread_mutex_unlock - The massif post outputs seem to need adjustments for some internal allocation patterns in glibc/libstdc++ Cheers, Mark |