Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1423434 - out of bounds stack access triggered by __sync_synchronize() on i686
Summary: out of bounds stack access triggered by __sync_synchronize() on i686
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 26
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1423318 1428286
TreeView+ depends on / blocked
Reported: 2017-02-17 10:20 UTC by Kamil Dudka
Modified: 2017-03-02 08:47 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1428286 (view as bug list)
Last Closed: 2017-03-01 20:35:32 UTC
Type: Bug

Attachments (Terms of Use)

Description Kamil Dudka 2017-02-17 10:20:10 UTC
Description of problem:
I see invalid (read) access to stack under valgrind on i686.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
$ mock -vr fedora-rawhide-i386 --init
$ mock -vr fedora-rawhide-i386 --install
$ mock -vr fedora-rawhide-i386 --install curl valgrind
$ mock -vr fedora-rawhide-i386 --no-clean --chroot 'valgrind curl -svo/dev/null'

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/
==15600==    by 0x62E88D0: ??? (in /usr/lib/
==15600==    by 0x62CE7C2: ??? (in /usr/lib/
==15600==    by 0x62CEC12: ??? (in /usr/lib/
==15600==    by 0x62CF944: ??? (in /usr/lib/
==15600==    by 0x62CFBFD: ??? (in /usr/lib/
==15600==    by 0x498BCC4: ??? (in /usr/lib/
==15600==    by 0x498C3EB: ??? (in /usr/lib/
==15600==    by 0x499A71F: SECMOD_LoadModule (in /usr/lib/
==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.

Comment 1 Kamil Dudka 2017-02-17 10:33:12 UTC
The minimal example seems to be as easy as:

int main()

==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

Switching to gcc...

Comment 2 Jakub Jelinek 2017-02-20 15:09:27 UTC
*** Bug 1425107 has been marked as a duplicate of this bug. ***

Comment 3 Jakub Jelinek 2017-02-20 15:12:54 UTC
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).

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

Comment 4 Mark Wielaard 2017-02-20 15:30:35 UTC
Thanks. The valgrind bug related to below stack accesses to implement memory fences on i386 is

Comment 5 Fedora End Of Life 2017-02-28 11:28:12 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 6 Jakub Jelinek 2017-03-01 20:35:32 UTC
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).

Note You need to log in before you can comment on or make changes to this bug.