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
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
