paulf38

These days OpenBSD aren’t testing code with Valgrind. IMO the move to limit syscalls to known libs like libc was not a very smart move. It totally breaks Valgrind and from what I’ve seen (I’m not a security expert) it isn’t difficult to circumvent https://isopenbsdsecu.re/mitigations/pinsyscall/.

I think that the point being made was that you cannot edit code with gdb and Valgrind, not that you can’t edit the code of gdb and Valgrind.

I look regularly, but all I see is tumbleweeds. Questions about Valgrind (my main interest) have shriveled from a few every week to about 1 every 3 months.

Sometimes I troll meta where the mods and “curators” (as they call themselves) hang out. The staff mods have finally twigged that indiscriminate close voting is a bad thing. A typical example of that would be an ego tripping “curator” that works on Windows with HTML and CSS voting to close a question about Linux OpenZFS library interfaces because the question is “not about programming”. I somehow fail to see how CSS experience qualifies a person to judge questions about ZFS.

It could have been either Valgrind or OpenSSL.

I call this UB exceptionalism. Your UB is bad and you need to fix it. My UB is a valid optimisation and the tools are producing false positives.

Valgrind only detects UB. We can do something for standard libraries that exploit this kind of UB - Valgrind replaces functions like strlcpy with its own versions that do not contain any UB. We can’t do that for all user libraries.

Who are ‘they’? OpenSSL?

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