> > > Acked-by: Christophe Fergeau <cfergeau@xxxxxxxxxx> > Just for ML reference. I discovered this issue quite long time ago. In another project and with Ubuntu I encountered it. I tried to understand, proved Valgrind had the issue (disassembly and so on). Did some search on internet and the issue occurred time ago and was fixed. Apparently however this happened again. Looks like this happens with some combination of Glibc (don't ask me why). I tried to fix the issue in Valgrind code but the hooking code was quite complicated (not even C but some specific script if I remember) and decided was not worth for me effort and by the way there was already some report/bug opened so I found the fortify workaround. Unfortunately even after an Ubuntu upgrade the problem seems still there :-( Some days ago Snir reported to me the problem with our gitlab CI, I proposed my workaround and we both tested that is working. I think Snir did some search on internet too, don't know if he pinged some report/bug or opened a new one. Frediano > On Tue, Apr 17, 2018 at 11:19:16AM +0100, Frediano Ziglio wrote: > > Due to a bug in current packaged Valgrind in the CI (1:3.13.0-13.fc27) > > check-valgrind is failing with: > > > > ==17986== Source and destination overlap in memcpy_chk(0x72c060, 0x72c068, > > 33) > > ==17986== at 0x4C344F0: __memcpy_chk (vg_replace_strmem.c:1581) > > ==17986== by 0x40E7E9: check_vmc_error_message > > (test-stream-device.c:166) > > ==17986== by 0x40EFD4: test_stream_device_format_after_data > > (test-stream-device.c:349) > > ==17986== by 0x7A012E9: test_case_run (gtestutils.c:2157) > > ==17986== by 0x7A012E9: g_test_run_suite_internal (gtestutils.c:2241) > > ==17986== by 0x7A0121A: g_test_run_suite_internal (gtestutils.c:2253) > > ==17986== by 0x7A014C1: g_test_run_suite (gtestutils.c:2329) > > ==17986== by 0x7A014E0: g_test_run (gtestutils.c:1594) > > ==17986== by 0x40951A: main (test-stream-device.c:410) > > ==17986== > > > > By default during CI build _FORTIFY_SOURCE is enabled, which turns memmove > > into __memmove_chk, which is wrongly turned into __memcpy_chk when running > > under Valgrind. > > Setting _FORTIFY_SOURCE to 0 prevents the use of __memmove_chk, and avoids > > triggering the Valgrind bug. > > > > Signed-off-by: Frediano Ziglio <fziglio@xxxxxxxxxx> > > --- > > This should be temporary till Valgrind is fixed in Fedora > > > > Changes since v1: > > - update commit message > > --- > > .gitlab-ci.yml | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > > index 535d220d..655232c2 100644 > > --- a/.gitlab-ci.yml > > +++ b/.gitlab-ci.yml > > @@ -34,7 +34,9 @@ check-valgrind: > > dnf install valgrind > > gstreamer1-libav gstreamer1-plugins-ugly gstreamer1-plugins-good > > gstreamer1-plugins-bad-free > > -y > > - - ./autogen.sh --enable-valgrind --enable-extra-checks > > + - > > > + CFLAGS='-O2 -pipe -g -D_FORTIFY_SOURCE=0' > > + ./autogen.sh --enable-valgrind --enable-extra-checks > > - make > > - make check-valgrind || (cat server/tests/test-suite-memcheck.log && > > exit 1) > > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel