#valgrind — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #valgrind, aggregated by home.social.
-
iai-callgrind gives you deterministic, instruction-count benchmarks. The catch: it needs Valgrind, and Valgrind has zero Apple Silicon support.
Here's how I run them locally on an M-series Mac in a native arm64 container - seccomp trap and all.
#rust #rustlang #performance #benchmarking #applesilicon #valgrind
https://martinhicks.dev/articles/running-iai-callgrind-on-apple-silicon
-
For those following valgrind stable release there is now valgrind 3.27.1 with some (regression) bug fixes.
-
#valgrind 3.27.0 released!
New options for helgrind (--show-events and --track-destroy), new SSE4.1 instruction for x86, support for s390x z/Architecture features from 15th edition, integrated binutils objdump for s390x disassembly, new linux syscalls, address space manager tracking linux kernel lightweight guard pages, freebsd 16.0-CURRENT, macOS up to version 13 Ventura (Intel), new client requests (VALGRIND_REPLACES_MALLOC, VALGRIND_GET_TOOLNAME).
https://gnu.wildebeest.org/blog/mjw/2026/04/20/anticipating-valgrind-3-27-0/
-
Anticipating #valgrind 3.27.0.
There are two new client requests (macros defined in valgrind.h) https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq
- VALGRIND_REPLACES_MALLOC Returns 1 if the tool replaces malloc (e.g., memcheck). Returns 0 if the tool does not replace malloc (e.g., cachegrind and callgrind) or if the executable is not running under VALGRIND.
- VALGRIND_GET_TOOLNAME Get the running tool name as a string. Takes two arguments, an input buffer pointer and the length of that buffer.
-
A lot of code in #valgrind 3.27.0 to support MacOS was previously maintained by Louis Brunner out of tree https://github.com/LouisBrunner/valgrind-macos
-
Anticipating #valgrind 3.27.0.
Paul Floyd @paulf had more commits than all others combined for this release. Paul takes care of the alternative toolchains, Solaris/illumos, FreeBSD and Darwin/MacOS ports.
Tested Oracle Solaris 11.4, OpenIndiana Hipster and OmniOS.
FreeBSD works on both amd64 and arm64, support for 16.0-CURRENT has been added.
Supported MacOS versions, 10.13 (bug fixes), 10.14, 10.15, 11.0 (Intel only), 12.0 (Intel only), 13.0 (Intel only, preliminary). No arm64 support yet
-
Anticipating #valgrind 3.27.0.
Martin also added Valgrind address space manager support for tracking linux kernel lightweight guard pages, created through madvise (MADV_GUARD_INSTALL).
These guard pages are very low overhead for the kernel because they aren't tracked as separate VMAs and don't show up in the process proc maps. But Valgrind does still need to know whether the addresses are accessible. A new --max-guard-pages option controls the memory Valgrind reserves for tracking these pages.
-
Anticipating #valgrind 3.27.0.
Martin Cermak maintains the Linux Test Program (LTP) valgrind integration, which checks our syscall wrappers work correctly. And he makes sure newer linux syscalls are wrapped. Valgrind 3.27.0 adds support for file_getattr, file_setattr, lsm_get_self_attr, lsm_set_self_attr, lsm_list_modules. And corrects various syscall and ioctl corner cases.
-
Anticipating #valgrind 3.27.0.
Andreas also showed there are still meaningful optimizations to be made on how memcheck tracks undefinedness bits as outlined in the original "Using Valgrind to detect undefined value errors with bit-precision" https://valgrind.org/docs/memcheck2005.pdf paper.
His optimization of memcheck instrumenting a bitwise AND/OR with a constant is clever and simplifies the generated code: https://sourceware.org/cgit/valgrind/commit/?id=8514763a215f863bc52400991eba332df115eaea
-
Anticipating #valgrind 3.27.0.
Andreas Arnez and Florian Krohm did a lot of work on the s390x support.
Andreas added support for new s390x z/Architecture features from the 15th edition. This enables running binaries compiled with -march=arch15 or -march=z17 and exploiting the new MSA extensions 10-13.
Florian Krohm integrated binutils objdump for s390x disassembly in VEX. And did a lot of s390x code and facilities cleanups.
s390x machine models older than z196 are no longer supported.
-
Anticipating #valgrind 3.27.0.
Valgrind has separate VEX IR translators for AMD64 and x86 (32 bit) code. While the AMD64 translator has seen support for new encodings and instruction sets, the x86 translator has not.
Alexandra Hájková decided to port the SSE4.1 instruction set from the AMD64 translator to the x86 translator and add backend support. This is ongoing work, see the bug dependency tree https://bugs.kde.org/showdependencytree.cgi?id=518222
But many more 32bit programs using SSE4.1 should now run under Valgrind.
-
Anticipating #valgrind 3.27.0.
Aaron Merey added two new options to helgrind.
To control helgrind tracing of internal synchronization, threading and memory events use --show-events=1|2|3.
Use --track-destroy=no|yes|all to checks for missing pthread_mutex_destroy and pthread_rwlock_destroy calls. With yes, helgrind warns when pthread_mutex_init or pthread_rwlock_init is called on the address of a live (undestroyed) lock. With all, Helgrind also reports undestroyed locks at process exit.
-
Valgrind 3.27.0-RC1 was released yesterday: https://sourceforge.net/p/valgrind/mailman/message/59321551/
There were 476 commits by 12 people with 58 bugs fixed since 3.26.0.
An RC2 should be available Fri Apr 17. The final 3.27.0 release is scheduled for Mon Apr 20.
Help testing is really appreciated.
-
Valgrind 3.27 RC1 is out
An RC1 tarball for 3.27.0 is now available at
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.txtPlease 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=valgrindAn RC2 should be available Fri Apr 17
The final 3.27.0 release is scheduled for Mon Apr 20. -
I've been finding a few issues in Valgrind on FreeBSD 16. Some are just the usual bit rot maintenance.
Two issues are more serious.
The first is because the servers that I was using have arm64/amd64-binutils installed on them. When they are installed clang will default to using them for linking rather than the LLVM linker. During startup Valgrind will try to read its own debuginfo (which it will use if it aborts to print its own callstack). FreeBSD does some funky things that when loading the ELF RW of an exe. I had added a nasty hacky hard coded bodge to handle that. This bodge assumed that if Valgrind is built with clang then the LLVM linker is being used. In this case that assumption was not satisfied, resulting in an assert firing. I've rewritten that code to be compiler (and linker) neutral without any hard coded values. It is still a nasty hacky bodge of course.
The second problem is a bit less serious. FreeBSD 16 switched to using the LLVM toolchain to produce split debuginfo files. Previously GNU ld.bfd was being used. The change has resulted in the split debuginfo files now containing ELF program headers. This broke some code that assumes that split debuginfo files do not contain ELF program headers. Fortunately this only triggers if you run Valgrind double verbose (-v -v) or higher. I'm working on a fix for this,
-
@kicad My code had a use after free, FFS, long standing random crashes finally tracked down - had to run a long valgrind checking apache logs to track it. #valgrind is awesome isn't.
You have to kick yourself over these a bit. A simple free(x) followed by using x is easy to spot and avoid.
A "get me this string from this XML object", and later "set this value in this XML object, which frees and reallocs and stores inside function" which causes previously fetched value to be now freed. Harder.
-
Just figured out what was causing an illumos Valgrind test failure. I was getting invalid reads/writes when functions with large locals were being called. I spent a long time digging through the Valgrind new/die stack mechanisms and then the code for creating the stack.
Then I noticed that with stack logging turned on that there was a new current_stack with id 1.
Hang on a sec, this is a monothread test and stack id 0 should be the only stack.
Some digging turned up Solaris "set_stack" that gets called from the syscall wrapper for getsetcontext with flag set to SETUSTACK. That gets called from ld.so for the main thread. That also means the main stack.
That results in a second stack registration for the main stack, with the stack range coming from Solaris rather than the one that we crafted at statup. These values are "wrong" compared to what Valgrind is expecting. Stack registration doesn't check for overlaps it just inserts the stack at the head of a list.
Some time after that there are stack writes and it's this 'new' main stack that gets used for accessibility checks. These accesses trigger false positive errors.
-
@mwl after this change: https://github.com/freebsd/pkg/commit/83243c7894afd319f009cc9135cc461767deea35 and thanks to #valgrind's massif tool, in a reference jail I used with LOTS of packages (including many package with plenty of files) the maximum memory peak for a pkg upgrade went from 1.4GB down to 199MB!
-
#NetBSD peeps! There is a (mostly) working #Valgrind implementation for NetBSD at https://github.com/paulfloyd/valgrind-netbsd. It would be great if we could get a (binary) package for it!
-
I've done the first version of my slides for FOSDEM. Now I need to practise my speach and see how many of the slides fit in.
-
Valgrind takes just over 24 hours to run through something in Darknet/YOLO.
Then it prompts once for every single issue it found. 7182 records:
==1747473== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----
- Is there a difference between uppercase and lowercase?
- I can guess what "n" and "y" means, but what is "c"? Cancel? Continue?This is not a time to start experimenting since it took me over 24 hours to get to this stage, and I cannot find the answer in the valgrind docs. #cpp #valgrind
-
Overhelming! All those tools around building software. #Jenkins, #Github actions, #Valgrind, #Docker, #Docross, #Qemu, and what the heck more. But unfortunately all of them waay too complex and feature-bloated for my taste. In addition, I'm absolutely NOT a fan of #SaaS. But what's the alternative then? ...
Read more:
https://hiddenalpha.ch/slnk/id/1-x0VwNWaFCdXy6kl3#SelfHosting #Virtualization #BuildEnv #Qemu #Container #Linux #BuildServer
-
Today's bug is a minor `valgrind` build system bug: https://bugs.kde.org/show_bug.cgi?id=511972
There `valgrind` probed at `./configure` time presence of `-W${flag}` support in `gcc` and used `-Wno-${flag}` to disable it. And it worked until https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=5b276d38c2fdd7df3d167755940da2038e049308
`gcc-16` will not allow countering `-Walloc-size-larger-than=42` with `-Wno-alloc-size-larger-than=42` any more. It has to be spelled as `-Wno-alloc-size-larger-than`.
-
This looks exciting. GO runtime: add valgrind instrumentation https://go-review.googlesource.com/c/go/+/674077
-
🎉 Wow, #Go added #Valgrind support! Now you can safely ignore memory leaks while you try to remember why you enabled #JavaScript just to read about it. 🙄🔍
https://go-review.googlesource.com/c/go/+/674077 #support #memoryleaks #HackerNews #HackerNews #ngated -
the idris2 docs suggest that a char* returned from an FFI will be `free`'d right away after making another copy.
the #ChezScheme docs do not explicitly state that (and I think idris2 is relying on chez scheme to do this), and #valgrind seems to suggest not.
-
#Valgrind is such an important tool. Especially when working with c libraries. Great work on #ghostty getting #gtk actually function for it. 😅
https://mitchellh.com/writing/ghostty-gtk-rewrite -
🚀 Wow, rewriting #Ghostty with #Zig and #GObject is like knitting a sweater with spaghetti - impressive, but why? 🤔 Meanwhile, using #Valgrind to verify memory is just a fancy way of saying "I found #bugs in my own code, again." 🍝💻
https://mitchellh.com/writing/ghostty-gtk-rewrite #programming #HackerNews #ngated -
#Valgrind https://valgrind.org not only tweaks your instruction stream it also wraps all your system calls so it knows all (memory) manipulation that goes on in your program (and to hide itself from the program it is running inside).
We integrated the #LTP https://linux-test-project.readthedocs.io syscalls testsuite with make ltpchecks
We are now down to ~50 failures https://builder.sourceware.org/testrun/fca661c30befd4e15b1b28e254a20c4d6420826a?amtestdir=ltp%2Ftests&filter_res=FAIL&perPage=50
All tracked in the meta bug dependency tree https://bugs.kde.org/showdependencytree.cgi?id=506971
Lets bring that count down to zarro boogs!
-
TIL: calling munmap() with wrong parameters can cause really strange occasional crashes in #AddressSanitizer or #Valgrind. Wrong parameters meaning in this case:
- passing wrong (too large) size,
- passing NULL,
- calling munmap() multiple times for the same pointer.Debugging the crashes was painful. What helped in the end was "doing the boring right thing": adding error checking to all related system calls, adding debug logs, fixing code smells.
-
TIL: calling munmap() with wrong parameters can cause really strange occasional crashes in #AddressSanitizer or #Valgrind. Wrong parameters meaning in this case:
- passing wrong (too large) size,
- passing NULL,
- calling munmap() multiple times for the same pointer.Debugging the crashes was painful. What helped in the end was "doing the boring right thing": adding error checking to all related system calls, adding debug logs, fixing code smells.
-
TIL: calling munmap() with wrong parameters can cause really strange occasional crashes in #AddressSanitizer or #Valgrind. Wrong parameters meaning in this case:
- passing wrong (too large) size,
- passing NULL,
- calling munmap() multiple times for the same pointer.Debugging the crashes was painful. What helped in the end was "doing the boring right thing": adding error checking to all related system calls, adding debug logs, fixing code smells.
-
TIL: calling munmap() with wrong parameters can cause really strange occasional crashes in #AddressSanitizer or #Valgrind. Wrong parameters meaning in this case:
- passing wrong (too large) size,
- passing NULL,
- calling munmap() multiple times for the same pointer.Debugging the crashes was painful. What helped in the end was "doing the boring right thing": adding error checking to all related system calls, adding debug logs, fixing code smells.
-
Sourceware Survey 2025 Results
In the end we got 103 (!) responses with a nice mix of developers, users and maintainers from various hosted projects.
https://sourceware.org/survey-2025
#binutils #cygwin #dwarfstd #elfutils #gcc #gdb #glibc #libabigail #newlib #systemTap #valgrind #bzip2 #libffi #dwz #debugedit #gnupoke #bunsen #lvm2 #annobin #gnu-gabi #cgen #kawa #insight #pacme
-
Sourceware Survey 2025 Results
In the end we got 103 (!) responses with a nice mix of developers, users and maintainers from various hosted projects.
https://sourceware.org/survey-2025
#binutils #cygwin #dwarfstd #elfutils #gcc #gdb #glibc #libabigail #newlib #systemTap #valgrind #bzip2 #libffi #dwz #debugedit #gnupoke #bunsen #lvm2 #annobin #gnu-gabi #cgen #kawa #insight #pacme
-
Sourceware Survey 2025 Results
In the end we got 103 (!) responses with a nice mix of developers, users and maintainers from various hosted projects.
https://sourceware.org/survey-2025
#binutils #cygwin #dwarfstd #elfutils #gcc #gdb #glibc #libabigail #newlib #systemTap #valgrind #bzip2 #libffi #dwz #debugedit #gnupoke #bunsen #lvm2 #annobin #gnu-gabi #cgen #kawa #insight #pacme
-
Sourceware Survey 2025 Results
In the end we got 103 (!) responses with a nice mix of developers, users and maintainers from various hosted projects.
https://sourceware.org/survey-2025
#binutils #cygwin #dwarfstd #elfutils #gcc #gdb #glibc #libabigail #newlib #systemTap #valgrind #bzip2 #libffi #dwz #debugedit #gnupoke #bunsen #lvm2 #annobin #gnu-gabi #cgen #kawa #insight #pacme
-
Friend @Computer I streamlined multiple levels of security by trouble shooting them. Our new security posture eliminates treacherous "defense in depth" wasted and disloyal effort. (This repeats earlier work that fixed #valgrind runs on #openssl, and of course recent similar improvements carried out by #doge_doofus)
-
Friend @Computer I streamlined multiple levels of security by trouble shooting them. Our new security posture eliminates treacherous "defense in depth" wasted and disloyal effort. (This repeats earlier work that fixed #valgrind runs on #openssl, and of course recent similar improvements carried out by #doge_doofus)
-
Friend @Computer I streamlined multiple levels of security by trouble shooting them. Our new security posture eliminates treacherous "defense in depth" wasted and disloyal effort. (This repeats earlier work that fixed #valgrind runs on #openssl, and of course recent similar improvements carried out by #doge_doofus)
-
Friend @Computer I streamlined multiple levels of security by trouble shooting them. Our new security posture eliminates treacherous "defense in depth" wasted and disloyal effort. (This repeats earlier work that fixed #valgrind runs on #openssl, and of course recent similar improvements carried out by #doge_doofus)
-
Friend @Computer I streamlined multiple levels of security by trouble shooting them. Our new security posture eliminates treacherous "defense in depth" wasted and disloyal effort. (This repeats earlier work that fixed #valgrind runs on #openssl, and of course recent similar improvements carried out by #doge_doofus)
-
Find Memory Leaks and Buffer Overrun Using Valgrind and Addresssanitizer (ASAN)
-
Debuginfod project update 2024 by Aaron Merey
https://developers.redhat.com/articles/2025/01/14/debuginfod-project-update-2024
- Metrics and scale of debuginfod servers #prometheus
- New tools and features in debuginfod #elfutils
- IMA verification support
- Addressing kernel VDSO extraction bottlenecks @osandov
- Lazy debug info downloading in #Valgrind and #GDB -
Built my first lisp (after already having started writing two compilers xD) in #zig! Mainly to test out the language, but it was much fun anyway.
It also got a few ideas for my own language for a few functional programming things :D
I enoyied the most the memory checking zig does, be it leaks, use-after-free or double-free, which makes this project the most easy to be memory-safe out of all my native (c-like) projects whithout multiple days using #valgrind xD
#foss #oss #opensource #programming #langdev #lisp #coding #c #c++ #zig #functionalprograming #compilerdev
-
[Перевод] Выявление ошибок в работе с памятью в C и C++: Сравниваем Sanitizers и Valgrind
В этой статье вашему вниманию представлено сравнение двух инструментов для поиска ошибок в работе с памятью в программах, написанных на memory-unsafe (небезопасных при работе с памятью) языках — Sanitizers и Valgrind . Эти два инструмента работают совершенно по-разному. Поэтому, хоть Sanitizers (разработанный инженерами Google) имеет ряд преимуществ перед Valgrind, у каждого из них есть свои сильные и слабые стороны. Следует сразу отметить, что проект Sanitizers имеет название во множественном числе, потому что он состоит из нескольких инструментов, которые мы рассмотрим в этой статье в совокупности.
https://habr.com/ru/companies/otus/articles/801123/
#работа_с_памятью #Sanitizers #Valgrind #динамические_структуры_данных
-
[Перевод] Выявление ошибок в работе с памятью в C и C++: Сравниваем Sanitizers и Valgrind
В этой статье вашему вниманию представлено сравнение двух инструментов для поиска ошибок в работе с памятью в программах, написанных на memory-unsafe (небезопасных при работе с памятью) языках — Sanitizers и Valgrind . Эти два инструмента работают совершенно по-разному. Поэтому, хоть Sanitizers (разработанный инженерами Google) имеет ряд преимуществ перед Valgrind, у каждого из них есть свои сильные и слабые стороны. Следует сразу отметить, что проект Sanitizers имеет название во множественном числе, потому что он состоит из нескольких инструментов, которые мы рассмотрим в этой статье в совокупности.
https://habr.com/ru/companies/otus/articles/801123/
#работа_с_памятью #Sanitizers #Valgrind #динамические_структуры_данных
