Please rebuild sqlite with gcc-7.0.1-0.10.fc26 or newer to make curl test-suite work again under valgrind on i686.  See the details below:


+++ This bug was initially created as a clone of Bug #1423434 +++

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.

--- Additional comment from Jakub Jelinek on 2017-03-01 21:35:32 CET ---

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).