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.
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.
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?
He tried ... but, no ... it still sucks. Brassy claims? Yeah, prob'ly so ... but, the claims are supported. Has issues? Sure ... but for most use cases, easy enough to work through. Covers all types of memory pools? Nope, didn't make that claim ;)
Besides, mine is intended to be a non-invasive memory counter, that's all. Want more invasive memory scoping? Write a MemCheck hook and generate all the metrics you want. Want to make sure your memory pool doesn't leak, you have to find another way. Oh well.
Thanks for checking it out, though. I've got a lot on my plate so issues with SigmaTest are expected. The core library I'm working on is putting SigmaTest through it's paces ... it's doing it's job and letting me know if I miss freeing something here or there. It's just a tool and it's helpful.
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.
reply