Created attachment 1255725 [details] minimal C reproducer extraceted from dbus code Description of problem: I run some of our test which use dbus and I found out that valgrinds test are failing on rawhide i386. There are some valgrind errors. And I can see then also in dbus unit tests. ==26500== Invalid read of size 4 ==26500== at 0x48A9100: _dbus_atomic_get (dbus-sysdeps-unix.c:2805) ==26500== by 0x4859171: _dbus_connection_close_if_only_one_ref (dbus-connection.c:2152) ==26500== by 0x4883340: handle_new_client_fd_and_unlock (dbus-server-socket.c:152) ==26500== by 0x4883340: socket_handle_watch (dbus-server-socket.c:213) ==26500== by 0x488FD9D: dbus_watch_handle (dbus-watch.c:758) ==26500== by 0x10E868: _dbus_loop_iterate (dbus-mainloop.c:827) ==26500== by 0x10C1EE: setup_connection (refs.c:270) ==26500== by 0x4C0D6ED: ??? (in /usr/lib/libglib-2.0.so.0.5102.0) ==26500== by 0x4C0D920: ??? (in /usr/lib/libglib-2.0.so.0.5102.0) ==26500== by 0x4C0DB30: g_test_run_suite (in /usr/lib/libglib-2.0.so.0.5102.0) ==26500== by 0x4C0DB5B: g_test_run (in /usr/lib/libglib-2.0.so.0.5102.0) ==26500== by 0x10A953: main (refs.c:635) ==26500== Address 0xfec7cbc8 is on thread 1's stack ==26500== 4 bytes below stack pointer But I found out that problematic line is "__sync_synchronize ()". So it's not bug in dbus but probably gcc. So I tried the same version of libdbus on fedora 25 and there was not any problem. Version-Release number of selected component (if applicable): sh$ rpm -q gcc valgrind gcc-7.0.1-0.8.fc26.i686 valgrind-3.12.0-3.fc26.i686 How reproducible: Deterministic on i686 Steps to Reproduce: 1. //Compile attached source code gcc -g3 dbus_minimal.c 2. // run the code with valgrind valgrind ./a.out Actual results: ==10957== Memcheck, a memory error detector ==10957== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==10957== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==10957== Command: ./a.out ==10957== after inc:0 ==10957== Invalid read of size 4 ==10957== at 0x804843C: _dbus_atomic_get (dbus_minimal.c:52) ==10957== by 0x8048489: main (dbus_minimal.c:63) ==10957== Address 0xfed38654 is on thread 1's stack ==10957== 4 bytes below stack pointer ==10957== after get:1 ==10957== ==10957== HEAP SUMMARY: ==10957== in use at exit: 0 bytes in 0 blocks ==10957== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==10957== ==10957== All heap blocks were freed -- no leaks are possible ==10957== ==10957== For counts of detected and suppressed errors, rerun with: -v ==10957== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 0 from 0) Expected results: O error: Here is an output from fedora rawhide x86_64 ==10957== Memcheck, a memory error detector ==10957== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==10957== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==10957== Command: ./a.out ==10957== after inc:0 after get:1 ==10957== ==10957== HEAP SUMMARY: ==10957== in use at exit: 0 bytes in 0 blocks ==10957== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==10957== ==10957== All heap blocks were freed -- no leaks are possible ==10957== ==10957== For counts of detected and suppressed errors, rerun with: -v ==10957== ERROR SUMMARY: 3 errors from 1 contexts (suppressed: 0 from 0)
Ups I wanted assign to gcc
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 bug has been marked as a duplicate of bug 1423434 ***
Please rebuild dbus with gcc-7.0.1-0.10.fc26 or newer Please do not forget to rebuild in f26 and rawhide