Initial work on this was started by an engineer at Intel. She was based in St Petersburg so that work stalled in 2022. Here is the bugzilla item https://bugs.kde.org/show_bug.cgi?id=383010. The other big issue is that we don't have enough people working on Valgrind that are experts with the virtual CPU. There are a couple of guys working on s390 and a little bit of work is being done reusing amd64 sse4 support on x86. I dabble a little bit on arm64,

If there are any AVX512 experts that would like to help with this it would be most welcome.

The following bugs have been fixed or resolved in this point release.

519574 valgrind 3.27 "--fair-sched=yes" does not work 519613 Valgrind incorrectly unpacks the result of sys_port (port_getn) on error, leading to a ~60s wallclock time delay on every call n-i-bz Update vg-lifespan (copyright) years n-i-bz Use SSizeT for VG_(readlink) result in VG_(realpath)

Comments URL: https://news.ycombinator.com/item?id=48221619

Points: 12

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47846162

Points: 1

# Comments: 0

An RC2 tarball for 3.27.0 is now available at https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.... (md5sum = 64b955764abeb80fd3e0b6287e596750) (sha1sum = a52b15d2f75619762fb1c5007e7c2c26d7e3711e) https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC2.tar.... Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

Please give it a try in configurations that are important for you and report any problems you have, either on this mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind

The final 3.27.0 release is scheduled for Mon Apr 20.

See my other reply for contents. Changed since RC0: Copyright notices, Linux fsconfig syscall fix, s390 instruction selection bug, macOS build failure from distribution tarballs, a few more opcodes handled on x86.

https://sourceware.org/git/?p=valgrind.git;a=blob;f=NEWS;h=d...

https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2

(md5sum = bd95111c1a9f81f136c5e4e2c62b493e) (sha1sum = 0eefb3a7d86a3bd0154480db3d2173bb8bd6d7c1) https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2.asc Public keys can be found at https://www.klomp.org/mark/gnupg-pub.txt

Please give it a try in configurations that are important for you and report any problems you have, either on the developer/user mailing list, or (preferably) via our bug tracker at https://bugs.kde.org/enter_bug.cgi?product=valgrind

An RC2 should be available Fri Apr 17

The final 3.27.0 release is scheduled for Mon Apr 20.

Comments URL: https://news.ycombinator.com/item?id=47763041

Points: 2

# Comments: 2

These days sourceware.org hosts the Valgrind git repo, buildbot CI and web site. We could also use their bugzilla. There isn't much point migrating as long as KDE can put up with us.

If anyone has the time and knowledge to help with AVX512 support then it would be most welcome. Fair warning, even with the initial work already done this is still a huge project.

Outside of Valgrind bugzilla bug reports these claims almost never stand up to close scrutiny. Not that the people making the claims ever perform any scrutiny. It's usually "my application doesn't crash so it must be a false positive" or "I'm sure that I initialised that variable" or "it's not really a leak, the OS will reclaim the memory".

Swift name-mangling will be an issue. Valgrind's name demangler comes from GNU binutils libiberty which does not support Swift AFAIK.

I love these folklore comments. Post an example.

Value semantics is the hot thing now I'd say.

Your library has many issues. Some should be easy to fix. You missed many allocation/deallocation functions (3 from ISO C, 1 from POSIX and 4 non-standard ones).

Others will be difficult or impossible for you to address. Your use of --wrap will not work with exes that link to static libc. macOS ld does not support --wrap. You will need to use another mechanism if you want to support macOS. I assume not supporting Windows is intentional.

The other big issue is with custom memory pools. That is always a difficult problem. Valgrind and the sanitizers require user instrumentation. Your leak detection will work with memory pools that just subdivide memory allocated with malloc etc. It won't work for memory pools that work like malloc itself and use brk/sbrk/mmap.

> Let’s make C testing suck less in 2025.

Didn't Bjarne Stroustrup do that already back in 1985?

Static analysis can cover all your code, though generally with a significant rate of false positives that you will need to analyse.

Mostly it wraps system calls and library calls. Wrapping means that it does some checking or recording before and maybe after the call. Very occasionally it needs to modify the arguments to the call. The rest of the time it passes the arguments on to the kernel or libc/libpthread/C++ lib.

There are also functions and syscalls that it needs to replace. That needs to be a fully functional replacement, not just looking the same as in mocking.

I don’t have any exact figures. The number of syscalls varies quite a lot by platform and on most platforms there are many obsolete syscalls that are not implemented. At a rough guess, I’d say there are something like 300 syscalls and 100 lib calls that are handled of which 3/4 are wrapped and 1/4 are replaced.

That is mostly wrong.

Valgrind wraps syscalls. For the most part it just checks the arguments and records any reads or writes to memory. For a small number of syscalls it replaces the syscall rather than wrapping it (for instance calls like getcontext where it needs to get the context from the VEX synthetic CPU rather than the real CPU).

Depending on the tool it can also wrap or replace libc and libpthread functions. memcheck will replace all allocation functions. DRD and Helgrind wrap all pthread functions.

The CPU and the hardware don’t care how confident C coders are in their ability.

C developers tend to forget the reason why Windows and UNIX like systems are now quite robust is that there has been over 50 years of turd polishing. Unfortunately for rust it is not immune to bugs other than memory safety issues. I think that it is a good idea to write new code in rust. Less so for battle hardened old code.

C++ is somewhere between C and rust. With modern ‘good practices’ (no raw pointers, no for loops) it can be an order of magnitude or two safer than C.