On Mon, Dec 5, 2016 at 12:02 PM, Bruce Dubbs <[email protected]> wrote:
> Bruce Dubbs wrote: > >> Douglas R. Reno wrote: >> >>> Bruce Dubbs wrote: >>> >>>> I have been checking out libevdev and get a bunch of failures when >>>> valgrind is installed. The errors look like: >>>> >>>> Running suite(s): libevdev_has_event tests >>>> ==1600== Source and destination overlap in memcpy(0x5b18463, 0x5b18462, >>>> 2) >>>> ==1600== at 0x4C2F463: memcpy (vg_replace_strmem.c:1019) >>>> ==1600== by 0x581DCD6: ??? (in /lib/libc-2.24.so) >>>> ==1600== by 0x581D853: readdir (in /lib/libc-2.24.so) >>>> ==1600== by 0x581DEAA: ??? (in /lib/libc-2.24.so) >>>> ==1600== by 0x421F81: fetch_device_node (libevdev-uinput.c:196) >>>> ==1600== by 0x4223EC: fetch_syspath_and_devnode >>>> (libevdev-uinput.c:230) >>>> ==1600== by 0x4223EC: libevdev_uinput_create_from_device >>>> (libevdev-uinput.c:405) >>>> ==1600== by 0x4228E2: uinput_device_create (test-common-uinput.c:151) >>>> ==1600== by 0x422B67: uinput_device_new_with_events_v >>>> (test-common-uinput.c:85) >>>> ==1600== by 0x422F2F: test_create_device (test-common.c:60) >>>> ==1600== by 0x409F7E: test_ev_bit_limits >>>> (test-libevdev-has-event.c:91) >>>> ==1600== by 0x4E3CB2C: tcase_run_tfun_fork (check_run.c:466) >>>> ==1600== by 0x4E3CB2C: srunner_iterate_tcase_tfuns (check_run.c:224) >>>> ==1600== by 0x4E3CB2C: srunner_run_tcase (check_run.c:373) >>>> ==1600== by 0x4E3CB2C: srunner_iterate_suites (check_run.c:195) >>>> ==1600== by 0x4E3CB2C: srunner_run (check_run.c:782) >>>> ==1600== by 0x40160B: main (test-main.c:86) >>>> >>>> There are a total of 74 errors in the first test and 3 in the second. >>>> >>>> I looked at libevdev-uinput.c and the line is: >>>> >>>> ndev = scandir(path, &namelist, is_event_device, alphasort); >>>> >>> >> I don't have any ideas directly, although I will note that Valgrind has >>> always been very flaky in terms of upstream changes. I remember having to >>> gen patches for Valgrind for every new version of Glibc, and even one or >>> two for new kernel API changes. >>> >>> What version of valgrind are you running? >>> >> >> I'm running version 3.12, but I think it is not a valgrind issue. From >> the above it is accurately saying that there is a Source and destination >> overlap from 0x5b18462 to 0x5b18463 for two bytes: >> >> That would mean: >> >> 0x5b18462 -> 0x5b18463 >> 0x5b18463 -> 0x5b18464 >> >> Which would loseo the original byte at 0x5b18463. I'm not sure if memcpy >> does it, but if it detected the overlap it could just reverse the order to >> make the copy: >> >> 0x5b18463 -> 0x5b18464 >> 0x5b18462 -> 0x5b18463 >> >> I tried to add an entry to valgrind.suppressions, but I haven't figured >> out the right syntax yet. >> > > It looks like a change in libc to me. On a system with libc-2.24.so it > fails as above, but with libc-2.22.so I do not get any test failures. > > Douglas, can you test libevdev-1.5.5 (just through make check) on your new > system? It tales 0.2 SBU with tests. > > > -- Bruce > > I most definitely can. It'll be a few hours first though before I can get to it. I'm still wiped from updating packages in the wee hours of the morning.
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
