On FreeBSD 13.1 calls to setproctitle() shall not trigger invalid read/write. That is, errors from setproctitle() in libc.so.7 shall be suppressed in freebsd.supp. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266036 and https://github.com/cyrusimap/cyrus-imapd/issues/4216 .
Please could you try the valgrind-devel port? It is currently ahead of the valgrind port and should work correctly with setproctitle, with the following change that I made back in July commit 9f27d8fbc733165d7b1afbc86f1b3cdcd3837cd1 Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Sun Jul 3 13:05:54 2022 +0200 Bug-456171 [PATCH] FreeBSD: Don't record address errors when accessing the 'kern.ps_strings' sysctl struct There is quite a lot of stuff here. The problem is that setproctitle and kern.ps_strings were using the Valgrind host auxv rather than the guest. The proposed patch would have just ignored those memory ranges. I've gone a fair bit further than that 1. refactored the initimg code for building the client auxv. Previously we were simply ignoring any non-scalar entries. Now we copy most of thse as well. That means that 'strtab' built on the client stack no longet only contains strings, at can also now contain binary structures. Note I was a bit concerned that there may be some alignment issues, but I haven't seen any problems so far. 2. Added intercepts to sysctl and sysctlbyname for kern.ps_strings, then find AT_PS_STRINGS from the client auxv that is now usable from step 1. 3. Some refactoring of sysctl and sysctlbyname syscall wrappers. More to do there! 4. Added a setproctitle testcase (that also tests the sysctls). 5. Updated the auxv testcase now that more AT_* entries are handled.
And with Valgrind from git head I get paulf> ../../valgrind/vg-in-place ./458378 ==11407== Memcheck, a memory error detector ==11407== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==11407== Using Valgrind-3.20.0.GIT and LibVEX; rerun with -h for copyright info ==11407== Command: ./458378 ==11407== http/caldav [unix socket] sdalu@sdalu.com GET ==11407== ==11407== HEAP SUMMARY: ==11407== in use at exit: 8,192 bytes in 3 blocks ==11407== total heap usage: 3 allocs, 0 frees, 8,192 bytes allocated ==11407== ==11407== LEAK SUMMARY: ==11407== definitely lost: 0 bytes in 0 blocks ==11407== indirectly lost: 0 bytes in 0 blocks ==11407== possibly lost: 0 bytes in 0 blocks ==11407== still reachable: 4,096 bytes in 2 blocks ==11407== suppressed: 4,096 bytes in 1 blocks ==11407== Rerun with --leak-check=full to see details of leaked memory ==11407== ==11407== For lists of detected and suppressed errors, rerun with: -s ==11407== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) For the 'still reachable' see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259294 I could add them to the suppression file awaiting any eventual libc freeres function.