@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.
I finally wrote out the last sections of the blog post I've been working on for what feels like months now!
https://wakelift.de/2026/03/09/making-your-jitted-code-known-let-me-count-the-ways/
This is a post only tangentially about #rakulang, more about #pldev, in particular a brief look at Stack Unwinding in general, followed by descriptions of the RtlAddFunctionTable function in the WinAPI, #libunwind's pendant, the "perf map" and "JITDUMP" formats that came from linux's perf utility, and the jit reader functionality in #gdb. There's a short mention of #valgrind at the end as well for good measure.
Thanks also to @tekknolagi who has a blog with related topics (and who already covered the perf map among other things that are also in my post)
AOT Compilers It has been normal and expected for a long long time that any machine code they spit out would come with a bunch of metadata that is meant to be used by different pieces of the target system. There is of course symbol names for functions, which allow
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.
Bah.
scalar: (skipping, prereq failed: kldstat -m mqueuefs > /dev/null 2>&1)
I need to spin up a FreeBSD 16 VM where I can load mqueuefs.
Fun Valgrind bugfixes of the week, number 2.
This time on illumos/Solaris amd64. I've been doing some testing on OmniOS and I noticed that the debug output (with the -d option) regularly contained corruption - a ctrl-b character - in long lines.
It seems like this is an old bug, git blame showing it as being present when the Solaris port was added to Valgrind back in 2015.
The issue was due to the debuglog function. This operates at a very low level - we want to be able to get debug logging very early on. Since we don't link with libc that means that we don't want it to even depend on our own heap manager. So roughly all it contains is a small 100 byte buffer on the stack, a vsprintf style function, a function to append 1 byte to the buffer and output the buffer when full and the function to write the buffer to file descriptor 2.
This last function is in inline assembler, and it is where the bug was. No registers were in the clobber list, but RDI is used to store the file descriptor, 2. Thart's STX or ctrl-b in ascii. Because RDI was modified it was changing the character in the first argument of the append to buffer function. After emptying the buffer the next character added was this corrupted ctrl-b character.
Fun Valgrind bugfixes of the week, number 1.
When you run 'valgrind' it's just a small wrapper binary that will exec the required tool (e.g., memcheck-amd64-netbsd). The wrapper needs to work out which CPU is required (since quite often 64bit arches also support 32bit binaries). It does that by looking at the ELF OSABI tag.
This was checking for UNIX System V or UNIX NetBSD.
However, if the executable uses GNU ifuncs the OSABI will be UNIX GNU. Since that wasn't handled it defaulted to Linux amd64. It then tried to exec memcheck-amd64-linux which resulted in a file not found error.
StΓ©phane Charette π¨π¦
RevK 
Timo the timo
paulf
bapt
benz