On Fri, Nov 08, 2013 at 05:50:31PM +0100, Jan Kratochvil wrote:
On Fri, 08 Nov 2013 17:21:02 +0100, Mark Wielaard wrote:
I admit I do not run testsuite under valgrind as it was too slow.
No worries, it really is very slow. That is why it is disabled by
default. But make distcheck does try to run all tests under valgrind.
Note that you can run make check -j4 if you have multiple cores to speed
things up a bit. Although it still takes long even then.
I tried now the commit before the unwinder master check-in
(22f867adcc1258aeb88560fa8591ef071353bb22):
I had to disable tests/run-nm-self.sh as it was running forever, maybe it would
end in some time but it was taking too many minutes.
Yes, that test tries all permutations of the command line flags on a long
list of files. It calls nm 4 * 3 * 3 = 36 times on all (20) self test files.
So that is 720 invocations. We might want to reduce that number a bit.
Then on the commit before unwinder
(22f867adcc1258aeb88560fa8591ef071353bb22)
I got:
FAIL: run-bug1-test.sh (exit: 1)
================================
==1150== Source and destination overlap in memcpy(0x4022000, 0x4022000, 64)
==1150== at 0x4C2C343: memcpy@(a)GLIBC_2.14 (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1150== by 0x4E45A4B: __elf64_updatemmap (elf32_updatefile.c:137)
==1150== by 0x4E41AAE: write_file (elf_update.c:87)
==1150== by 0x4E41E0A: elf_update (elf_update.c:196)
==1150== by 0x400977: main (rdwrmmap.c:38)
That is indeed a real bug (though mostly harmless). I have a patch.
> Or by hand:
>
LD_LIBRARY_PATH=~/build/elfutils-obj/backends:~/build/elfutils-obj/libelf:~/build/elfutils-obj/libdw
valgrind --run-libc-freeres=no src/addr2line -S -e test-core.exec --core=test-core.core
0x7f67f2aaf619
For the master commit (=with unwinder) I really get:
valgrind: m_redir.c:700 (vgPlain_redir_add_ifunc_target): Assertion 'old'
failed.
==9785== at 0x38059B6F: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==9785== by 0x38059CB2: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==9785== by 0x3806A40D: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==9785== by 0x3809F787: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
==9785== by 0x380AE0FC: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==9785== at 0x4A237CC: _vgnU_ifunc_wrapper (in
/usr/lib64/valgrind/vgpreload_core-amd64-linux.so)
==9785== by 0x400E99E: _dl_fixup (dl-irel.h:32)
==9785== by 0x40152A4: _dl_runtime_resolve (dl-trampoline.S:45)
==9785== by 0xC3ABCF9: x86_64_core_note (linux-core-note.c:210)
==9785== by 0x4E743C3: ebl_core_note (eblcorenote.c:54)
==9785== by 0x4E6EE16: __libdwfl_attach_state_for_core (linux-core-attach.c:333)
==9785== by 0x4E6AE52: dwfl_core_file_report@(a)ELFUTILS_0.158 (core-file.c:565)
==9785== by 0x4E5CF8B: parse_opt (argp-std.c:317)
==9785== by 0x53A6927: ??? (in /usr/lib64/libc-2.17.so)
==9785== by 0x401BDA: main (addr2line.c:149)
Yeah, so that really seems to be a bug in valgrind.
Thanks,
Mark