On 09-05-2015 10:46, Douglas R. Reno wrote:
> Hi All,
>
> As I am going through my tagging journey, I seem to be having issues
> with the Valgrind test suite. I hear all over the internet that it
> does not work, and I get the following errors out of it (and running a
> "make -k regtest" does absolutely nothing for this)
>
> == 611 tests, 18 stderr failures, 0 stdout failures, 0 stderrB
> failures, 3 stdoutB failures, 2 post failures ==
> gdbserver_tests/hgtls (stdoutB)
> gdbserver_tests/nlcontrolc (stdoutB)
> gdbserver_tests/nlvgdbsigqueue (stdoutB)
> memcheck/tests/demangle (stderr)
> memcheck/tests/err_disable3 (stderr)
> memcheck/tests/err_disable4 (stderr)
> memcheck/tests/leak_cpp_interior (stderr)
> memcheck/tests/overlap (stderr)
> memcheck/tests/threadname (stderr)
> memcheck/tests/threadname_xml (stderr)
> massif/tests/new-cpp (post)
> massif/tests/overloaded-new (post)
> helgrind/tests/tc12_rwl_trivial (stderr)
> helgrind/tests/tc20_verifywrap (stderr)
> drd/tests/bar_bad_xml (stderr)
> drd/tests/hold_lock_1 (stderr)
> drd/tests/hold_lock_2 (stderr)
> drd/tests/std_thread (stderr)
> drd/tests/std_thread2 (stderr)
> drd/tests/tc12_rwl_trivial (stderr)
> drd/tests/tc18_semabuse (stderr)
> drd/tests/thread_name_xml (stderr)
> drd/tests/trylock (stderr)
> I would like to propose that we set the Valgrind test suite to "This
> package does not come with a working test suite" at this point. I have
> also tried the test suite on my GCC 4.9.2 system as well, and I get
> similar results.
Similar results is good.
Douglas, considering the number of tests and failures, they are not useless.
(Interesting that I'm between the two extremes, today: Pierre
recommending a test suite, you with the opposite intention.)
I've found that their nightly builds come with different failures from
one day to the other. The devs are aware of that, so they ask for user
input [1]:
{{{
bugzilla: https://bugs.kde.org/buglist.cgi?product=valgrind
Please, please, please file issues for everything.
}}}
Devs talk about the failures [2]:
{{{
Figure out why there are failing tests.
Hard because depends on:
architecture/instruction set
kernel version
glibc version
random stuff
}}}
Comparing our results, the difference is small.
Douglas:
== 611 tests, 18 stderr failures, 0 stdout failures, 0 stderrB failures,
3 stdoutB failures, 2 post failures ==
Less than 4%.
Fernando:
== 620 tests, 19 stderr failures, 0 stdout failures, 0 stderrB failures,
3 stdoutB failures, 2 post failures ==
Still less than 4%.
Douglas, not Fernando:
drd/tests/tc12_rwl_trivial (stderr)
drd/tests/tc18_semabuse (stderr)
drd/tests/thread_name_xml (stderr)
drd/tests/trylock (stderr)
Fernando, not Douglas:
drd/tests/pth_barrier_thr_cr (stderr)
Considering that we have 19 common failures, it is probable that in
(B)LFS we do something the valgrind developers didn't expect.
One possible problem [3]:
{{{
Do not ship your Linux distro with a completely stripped /lib/ld.so. At
least leave the debugging symbol names on -- line number info isn't
necessary.
}}}
Is it stripped in LFS?
I think we could post our logs at anduin and users we could be sent
there when asking.
And also include a comment in the book.
[1]
https://fosdem.org/2015/schedule/event/valgrind_easy_hack/attachments/slides/731/export/events/attachments/valgrind_easy_hack/slides/731/valgrind_easy_hacks.html#slide5
[2]
https://fosdem.org/2015/schedule/event/valgrind_easy_hack/attachments/slides/731/export/events/attachments/valgrind_easy_hack/slides/731/valgrind_easy_hacks.html#slide4
[3]
https://fosdem.org/2015/schedule/event/valgrind_easy_hack/attachments/slides/731/export/events/attachments/valgrind_easy_hack/slides/731/valgrind_easy_hacks.html#slide21
--
[]s,
Fernando
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
