From ff1c34294d6ed18b056cb1d6f3a88d1b5cdef2c1 Mon Sep 17 00:00:00 2001 From: Paul Floyd Date: Fri, 26 Sep 2025 19:02:12 +0200 Subject: [PATCH] Valgrind status report This is a bit late. Our fibre connection at home is not working so this is a bit late and probably has quite a few errors in it. --- .../report-2025-07-2025-09/valgrind.adoc | 53 +++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 website/content/en/status/report-2025-07-2025-09/valgrind.adoc diff --git a/website/content/en/status/report-2025-07-2025-09/valgrind.adoc b/website/content/en/status/report-2025-07-2025-09/valgrind.adoc new file mode 100644 index 00000000000..ee8cdf862a3 --- /dev/null +++ b/website/content/en/status/report-2025-07-2025-09/valgrind.adoc @@ -0,0 +1,53 @@ +=== Valgrind: preparing for 15.0-RELEASE + +Links: + +link:https://www.valgrind.org/[Valgrind Home Page] URL: link:https://www.valgrind.org/[] + +link:https://www.valgrind.org/docs/manual/dist.news.html[Valgrind News] URL: link:https://www.valgrind.org/docs/manual/dist.news.html[] + +link:https://github.com/paulfloyd/freebsdarm64_valgrind[arm64 port] URL: link:https://github.com/paulfloyd/freebsdarm64_valgrind[] + +Contact: Paul Floyd + +I have not submitted any reports for over a year. On the whole that is good news as it means that there have not been any major issues. Back then I said that aarch64 support was about to land and indeed it dit in mid April 2024. + +I added a nice little script for use with Valgrind called `vgscript`. This works in a similar manner to `pstack` (or `bstack` on FreBSD) in that you give it a PID and it will generate a stack trace for that process. If you use `bstack` with a Valgrind process you will see the Valgrind call stack which is probabably of no use to you. If you run `vgstack` with a Valgrind PID it will print the call stack of the test exe running under Valgrind. + +If you use Valgrind regularly could you take a look and answer the survey that I posted on the forums (if you have not done so already). Here is the link https://forums.freebsd.org/threads/valgrind-feature-poll.98707/#post-716085 . + +Valgrind 3.26 is due out at the end of October 2025 and package:devel/valgrind[] will be updated shortly after that. + +package:devel/valgrind-devel[] will get one (or maybe more) updates as I fix issues with FreeBSD 15.0. + +The oustanding issues that I have on FreeBSD 15.0 are +* aarch64: there is a problem when using Valgrind with gdb/vgdb. Hitting ctrl-c to interrupt the process running under Valgrind does not work and Valgrind crashes with an assert. +* aarch64: a known old issue that was infrequent regarding initialisation of thread memory now seems to occur much more often. +* amd64: maybe simular to the first issue with gdb/vgdb and interrupting a process, but this time I'm seeing `select` return an 'impossible' value. +* amd64: a test for `setcred` is getting an extra "Conditional jump" error message. + +Most of the above are not too serious unless you are a heavy user of gdb/vgdb. + +Here is a list of bugfixes since my last report, Q1 2024. + +* Several suppressions added for libc, libc++ and libstdc++ functions +* Improvements to `setcontest` argument checking +* Some more `aio_*` fixes +* Syscall `_sysctlname` was checking the wrong length of the name argument +* New syscall wrappers for `kcmp`, `getrlimitusage`, `close_range`, `fchroot`, `setcred`, `exterrctl`, `inotify_add_watch_at`, `inotify_rm_awtch`, `jail_attach_jd` and `jail_remove_jd` +* Started adding better `ioctl` argument checking +* Fixes to Valgrinds sekf-checking modes +* Support aarch64 auxv AT_HWCAP, AT_CHERI_STATS, AT_HWCAP3 and AT_HWCAP4 +* Valgrind faile descriptor checking has been significantly enhanced and this includes FreeBSD +* Some old code that I could never test for FreeBSD 10 has been removed +* Removed as much as possible FreeBSD version dependent code. This reduces everyday maintenance at the cost of making version-independent regression tests more difficult +* Turn off check for lock created during atext handling that will deliberately leak +* Syscall `sigwait` was not correctly dealing with its atypical return value +* Improved checking of `utrace` syscall arguments +* amd64: syscal arguments 7 and 8 were swapped (it turns out that argument 8 is never needed and has been removed) +* amd64: added `sysarch` subcommands `AMD64_SET_TLSBASE` and `AMD_GET_TLSBASE` +* Reduced warnings that get printed in quiet (-q) mode +* Improved checking done by `sysctl` kern.proc.pathname +* Handle `mmap` MAP_STACK and MAP_GUARD +* Syscalls `open*` now produce an error if you try to open the guest exe for writing +* Syscalls `sigwait` and `sigwaitingfo` were too lax in accepting NULL arguments +* Many of the `*at` system calls (like `faccessat`) were not checking that the directory fd is not one of the file descriptors reserved for Valgrind's use +* Function `memalign` now accepts a size of zero +