Description of problem: I see invalid (read) access to stack under valgrind on i686. Version-Release number of selected component (if applicable): sqlite-libs-3.16.2-3.fc26.i686 How reproducible: Reliably. Steps to Reproduce: $ mock -vr fedora-rawhide-i386 --init $ mock -vr fedora-rawhide-i386 --install https://kojipkgs.fedoraproject.org//packages/sqlite/3.16.2/3.fc26/i686/sqlite-libs-3.16.2-3.fc26.i686.rpm https://kojipkgs.fedoraproject.org//packages/sqlite/3.16.2/3.fc26/i686/sqlite-debuginfo-3.16.2-3.fc26.i686.rpm $ mock -vr fedora-rawhide-i386 --install curl valgrind $ mock -vr fedora-rawhide-i386 --no-clean --chroot 'valgrind curl -svo/dev/null https://google.com' Actual results: ==15600== Invalid read of size 4 ==15600== at 0x6311D17: UnknownInlinedFun (sqlite3.c:23079) ==15600== by 0x6311D17: sqlite3MutexInit (sqlite3.c:22651) ==15600== by 0x6329854: sqlite3_initialize (sqlite3.c:139163) ==15600== by 0x6352A73: sqlite3_mprintf (sqlite3.c:25881) ==15600== by 0x62E484D: ??? (in /usr/lib/libsoftokn3.so) ==15600== by 0x62E88D0: ??? (in /usr/lib/libsoftokn3.so) ==15600== by 0x62CE7C2: ??? (in /usr/lib/libsoftokn3.so) ==15600== by 0x62CEC12: ??? (in /usr/lib/libsoftokn3.so) ==15600== by 0x62CF944: ??? (in /usr/lib/libsoftokn3.so) ==15600== by 0x62CFBFD: ??? (in /usr/lib/libsoftokn3.so) ==15600== by 0x498BCC4: ??? (in /usr/lib/libnss3.so) ==15600== by 0x498C3EB: ??? (in /usr/lib/libnss3.so) ==15600== by 0x499A71F: SECMOD_LoadModule (in /usr/lib/libnss3.so) ==15600== Address 0xfe9a5bec is on thread 1's stack ==15600== 4 bytes below stack pointer Expected results: valgrind output is clean. Additional info: This breaks nss-softokn and consequently curl. Everything works as expected after downgrading to sqlite-libs-3.16.2-2.fc26.i686. So it is most likely a new version of the compiler what triggered this bug.
The minimal example seems to be as easy as: int main() { __sync_synchronize(); } ==18365== Invalid read of size 4 ==18365== at 0x80483D9: main (test.c:3) ==18365== Address 0xfec676b4 is on thread 1's stack ==18365== 4 bytes below stack pointer # rpm -q gcc valgrind gcc-7.0.1-0.8.fc26.i686 valgrind-3.12.0-3.fc26.i686 Switching to gcc...
*** Bug 1425107 has been marked as a duplicate of this bug. ***
This has been reverted upstream today, the lock orl $0, -4(%esp) form of mfence has been done that way for performance reasons, but people who care about performance should not be using 32-bit code anyway, so it will be again lock orl $0, (%esp). See http://gcc.gnu.org/r245577 This will be picked by Fedora gcc mid to late this week, then you'll need to rebuild anything that uses __sync_synchronize or similar atomic barriers and you care about running it under valgrind in 32-bit mode (the code is really harmless, because it doesn't change the word below sp, but valgrind is still unhappy about that).
Thanks. The valgrind bug related to below stack accesses to implement memory fences on i386 is https://bugs.kde.org/show_bug.cgi?id=374940
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
Should be fixed in gcc-7.0.1-0.10.fc26. You need to rebuild 32-bit packages that use such barriers and you want to run them under valgrind (outside of valgrind it is really harmless).