I filed the (related, closed) bug #1102495 some time ago, and after being asked to refile in various places I've got a message on Launchpad from Valgrind. I think it's relevant to this conversation, but to be honest this is all way over my head, so apologies if this is just noise :)
My read is that valgrind recommends disabling -fstack-clash-protection, but I've probably misunderstood something. Please see the full thread below or at https://bugs.launchpad.net/raspbian/+bug/2106733 (which will soon have a note about how I wrote this after [email protected] bounced). ----- Forwarded message from Andrew Sayers <[email protected]> ----- Date: Mon, 17 Nov 2025 19:08:24 -0000 From: Andrew Sayers <[email protected]> To: [email protected] Subject: [Bug 2106733] Re: dpkg-dev calls gcc with settings that break valgrind CCing [email protected], as I think some of this goes there. (I'm just an ordinary valgrind user who stumbled over a bug) Debian and Raspbian are unrelated projects, with Raspbian mostly downstream of Debian. It sounds like your libarmmem.so issue is aimed at Raspbian, but your suppression file issue is aimed at Debian? Note: Debian's "armhf" builds use ARMv7, Raspbian "armhf" builds use ARMv6. I'm not sure whether that's part of this problem, but please be aware the two projects use the same word to mean different things. I think you're saying you're aware of the 2018 Procedure Call Standard mentioned in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102495#11 but don't recognise it as an actual standard? (not taking a position, just making sure we're on the same page) I'm afraid the technology discussion goes beyond my understanding, but it sounds like the conversation is heading towards the following: 1. close https://bugs.kde.org/show_bug.cgi?id=479699 as WONTFIX 2. disable stackclash in Debian 3. wait for the fix to naturally make its way into Raspbian On Sun, Nov 16, 2025 at 08:45:28PM -0000, Pjfloyd wrote: > Upstream Valgrind developer here. > > If you want to get taken seriously, then you could start by updating > libarmmem.so on RPi OS 32bit. See > https://bugs.launchpad.net/raspbian/+bug/2051392. > > I just looked at your suppression file > > https://sources.debian.org/src/valgrind/1%3A3.25.1-3/debian/supp/armhf- > stackclash.supp > > You do realize that with a single top level wildcard this suppresses ALL > memcheck invalid reads and writes of size 4 bytes? That's a seriously > bad mistake in my view. It looks like RedHat did the right thing and > stopped using -fstack-clash-protection > > "only if valgrind upstream gets updated to properly support recent > standards" > > I'm also a member of the ISO C++ committee, and I've never heard of any > stack clash standards. From what I see it's a non-standard extension > added by GCC and also picked up by non-Apple LLVM. > > In general we are reluctant to add workarounds to such protections to > Valgrind. There is some benefit to checking that builds with and without > protections are equivalent. Otherwise it just makes things more > difficult and adds no benefit to the debugging process. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/2106733 > > Title: > dpkg-dev calls gcc with settings that break valgrind > > Status in Raspbian: > New > > Bug description: > This issue is about a cluster of problems caused by interactions > between several packages. > > `gcc -fstack-clash-protection` on Pi armhf bookworm generates binaries > that cause false positives in valgrind. See > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102495 for details. > > As discussed in the link above, `gcc -fstack-clash-protection` on Debian > armhf can also crash valgrind. See > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061496 for details. I > can't replicate that on my > Pi, but it suggests the bug I reported is just one of many. > > `dpkg-dev` sets `-fstack-clash-protection` by default on all platforms > where it is supported. So if I create a package with `dpkg-dev`, any > binaries in that package will be too full of false positives to > usefully debug with valgrind. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102495#11 includes > this: > > > When we chose to turn stackclash on I thought the advantages would > > outweight the disadvantages, but I was wrong. I think we should > > reconsider the decision and re-enable stackclash on armhf only if > > valgrind upstream gets updated to properly support recent standards. > > That's about re-enabling in Debian after Trixie, because the most > common bug has already been suppressed in Debian. I'd recommend > either importing the suppression mentioned in that post, or disabling > `-fstack-clash-protection` altogether. > > I previously reported this at https://github.com/raspberrypi/bookworm- > feedback/issues/405 but was asked to resubmit here. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/raspbian/+bug/2106733/+subscriptions > > ** Bug watch added: Debian Bug tracker #1102495 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102495 ** Bug watch added: KDE Bug Tracking System #479699 https://bugs.kde.org/show_bug.cgi?id=479699 ** Bug watch added: Debian Bug tracker #1061496 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061496 -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/2106733 Title: dpkg-dev calls gcc with settings that break valgrind Status in Raspbian: New Bug description: This issue is about a cluster of problems caused by interactions between several packages. `gcc -fstack-clash-protection` on Pi armhf bookworm generates binaries that cause false positives in valgrind. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102495 for details. As discussed in the link above, `gcc -fstack-clash-protection` on Debian armhf can also crash valgrind. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061496 for details. I can't replicate that on my Pi, but it suggests the bug I reported is just one of many. `dpkg-dev` sets `-fstack-clash-protection` by default on all platforms where it is supported. So if I create a package with `dpkg-dev`, any binaries in that package will be too full of false positives to usefully debug with valgrind. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102495#11 includes this: > When we chose to turn stackclash on I thought the advantages would > outweight the disadvantages, but I was wrong. I think we should > reconsider the decision and re-enable stackclash on armhf only if > valgrind upstream gets updated to properly support recent standards. That's about re-enabling in Debian after Trixie, because the most common bug has already been suppressed in Debian. I'd recommend either importing the suppression mentioned in that post, or disabling `-fstack-clash-protection` altogether. I previously reported this at https://github.com/raspberrypi/bookworm- feedback/issues/405 but was asked to resubmit here. To manage notifications about this bug go to: https://bugs.launchpad.net/raspbian/+bug/2106733/+subscriptions ----- End forwarded message -----
