paulf38

"valgrind and msan will give you an immediate and false positive message"

Why a false positive? Are you one of those people that 'knows' that their code is correct and always blames the tool? What you describe sounds like a real error. Sort of. The error is not triggered by reading the value, it gets triggered when it is used in some conditional context and the undefinedness has an observable impact on the execution of the program.

This is a change from undefined/erroneous behaviour to something else - defined but maybe not what you wanted.

I agree that this can make error analysis more difficult.

Is that something that should be merged to upstream Valgrind?

And sadly that was one that I broke trying to refactor together all our C++ autoconf tests. Silver lining, I added a test for it so if I break it again we should notice earlier.

"some community effort" is a huge understatement. Let me rephrase that for you: "Possibly the largest ever single contribution to Valgrind".

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.

3.27.0 RC2 is now out.

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.

For the contents, see

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

AI slop.

We still use KDE's bugzilla. One of the reasons that Vagrind was initially developed was to help with KDE back when many developers didn't really understand how to use new and delete.

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.

There was someone at Intel working on AVX512 support in Valgrind. She is/was based in St Petersburg. Intel shuttered their Russian operations when Putin invaded Ukraine and that project stalled.

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.

The problem is that there are many many people that are falling over themselves to believe bogus claims about false positives.

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".

I'm working on Valgrind on macOS, integrating Louis Brunner's work and trying to add a few more fixes. In 2025 support for macOS Intel 10.14, 10.15 11 and 12 was added. Intel macOS 13 is a bit harder of a nut to crack. And I have lots of issues with ARM, particularly building and testing on anything older that macOS 15.

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

If anyone can help adding AVX512 (and other CPU features) support then that would be most welcome. It’s a major task though.

> even with Valgrind and similar tools, you are still going to run into weird destructor issues with inheritance.

I love these folklore comments. Post an example.

In my experience that is usually the result of years and years of accumulation of shit code. The results is thousands of leaks. That makes detection of incremental leaks much more difficult. If you start with clean code and use ASAN or Valgrind then leak detection is not difficult.

OOP is pretty much has-been.

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

Rather brassy claims.

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?

Valgrind (and the sanitizers) are only as good as your test coverage.

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

Are you trying to explain to me how Valgrind works? If you do know more than me then please join us and become a Valgrind developer.

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.

> Valgrind is a mock of standard library/OS functions and I think its existence is a good thing.

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.

I agree that C is a basket case when it comes to safety and security.

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.

I do most of the Valgrind maintenance these days.

I wrote a series of articles for ACCU overload back around 2012 to 2013. This was in 6 parts. Introduction https://accu.org/journals/overload/20/108/floyd_1930/ Basic memcheck https://accu.org/journals/overload/20/109/floyd_1913/ Advanced memcheck https://accu.org/journals/overload/20/110/floyd_1905/ Cachegrind and Callgrind https://accu.org/journals/overload/20/111/floyd_1886/ Massif https://accu.org/journals/overload/20/112/floyd_1884/ Helgrind and DRD https://accu.org/journals/overload/21/114/floyd_1867/

More recently I wrote another one DHAT https://accu.org/journals/overload/33/185/floyd/

The videos on YouTube are mostly crap. Here are a couple of good ones https://www.youtube.com/watch?v=-VDiEe9hxC4&lc=UgwLVU1SO1BUz... https://www.youtube.com/watch?v=y6AN0ks2q0A&lc=UgwQSQzkCtMRO...

Nooooo! "valgrind memory leak". Aaargh. Valgrind (memcheck) is not just a leak detection tool. Leak detection is so unimportant that it isn't even turned on by default.

In what way are the error reports "just noise"?

You didn't look very hard. The person that I replied to said " Disciplined use of c, with modern tools like valgrind, will give you safe code".

TBH most “false positives” that I investigate are wishful thinking or the result of ignorance of what is really happening. It looks like you are using Debian. That probably doesn’t help. Here is a typical Debian “bug” report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778

10 years old. It never was a false positive. It was fixed a good few years ago. The fix did not involve suppressing the error.

Valgrind does need a lot of work, especially for missing CPU features and for Darwin. I’m not aware of many memcheck bugs that aren’t relatively obscure corner cases.

If you have encountered bugs please report them to https://bugs.kde.org.

It would be nice (speaking as a Valgrind developer) if Valgrind could guarantee safe code. Unfortunately it doesn’t. Firstly, it does not detect all kinds of errors (and indeed no tool does). Secondly, it is unlikely that the test coverage is perfect.

Delusional overconfidence that developer “skill” is all that is needed to overcome the many shortcomings of C is not a solution to the problem of guaranteeing security and safety.

I always assume that anyone that says that something is a false positive without providing any rigorous proof has confirmation bias and are sadly deluding themselves about their ability and the correctness of their code.

Valgrind has a long history, it is now about 23 years old. Over that period it has used several systems to host the source repo, web site and bug database.

At the time of writing, sourceware hosts both the web site and git repo, sourceforge hosts the mailing lists and KDE hosts our bugzilla bug database.

Yes indeed. The backdoor author did try to claim that it was a false positive (and I’m sure that a very depressingly large number of people would happily go along with such a claim even without a scrap of evidence).

The error was related to the use of the frame pointer. Optimised code does not use RBP as the frame pointer, only using RSP for stack addresses. The XZ backdoor code assumed that the stack used this layout. The RedHat regression tests use debug builds that do use the frame pointer. The result was the backdoor code writing below the bottom of the stack.

I suspect also that Valgrind is unique in finding issues like this. Other tools do not check all memory accesses before main. Valgrind loads and runs the test binary from the very beginning and thus it detected errors in the ifunc code used by XZ that executed very early on during ld.so loading and symbol resolution.