Skip to content

Valgrind status report #553

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Valgrind status report #553

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions website/content/en/status/report-2025-07-2025-09/valgrind.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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 <[email protected]>

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
I added a nice little script for use with Valgrind called `vgscript`. This works in a similar manner to `pstack` (or `bstack` on FreeBSD) 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 .
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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 .
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[link].


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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: maybe similar 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Fixes to Valgrinds sekf-checking modes
* Fixes to Valgrind self-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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Valgrind faile descriptor checking has been significantly enhanced and this includes FreeBSD
* Valgrind file 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Turn off check for lock created during atext handling that will deliberately leak
* Turn off check for lock created during text 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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change