Piero Bosio Social Web Site Personale

Valgrind 3.27 RC1 is outAn RC1 tarball for 3.27.0 is now available athttps://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.ascPublic keys can be found at https://www.klomp.org/mark/gnupg-pub.txtPlease give it a try in configurations that are important for you andreport any problems you have, either on the developer/user mailing list, or(preferably) via our bug tracker athttps://bugs.kde.org/enter_bug.cgi?product=valgrindAn RC2 should be available Fri Apr 17The final 3.27.0 release is scheduled for Mon Apr 20.#valgrind

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.#ilumos #valgrind

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 #OpenBSD #NetBSD #dragonflybsd