Douglas R. Reno wrote:
On Mon, Oct 31, 2016 at 7:16 PM, Bruce Dubbs <[email protected]> wrote:
Douglas R. Reno wrote:
On Mon, Oct 31, 2016 at 5:34 PM, Bruce Dubbs <[email protected]>
wrote:
I'm trying to update valgrind to version 3.12.0 for the book. The build
is fine, but I get over 1000 test failures.
I did rebuild a debug version of ld-2.24.so and that got a reduction to
166 test failures. It looks like there are a lot of issues with other
glibc libraries without debug symbols or just differences (4 bytes freed
vs
8 bytes freed) in the latest glibc and/or kernel.
I'm looking for suggestions about how to handle this in the book.
I probably wouldn't have noticed this, as I have no desire whatsoever to
strip my libraries. I'm not concerned about size. Without stripped
libraries, I don't get as many failures, at least according to one of my
old logs.
We could do something about this in the valgrind page, but GDB goes
through
the same thing. Do we really need to strip libraries?
The page in LFS Section 6.72 Stripping Again says that users not doing
debugging don't need to do it. A lot of users do not run tests and thus do
not have any problems. It mostly comes up for editors running tests after
building a new package version.
I suppose we could add role="nodump" to the xml in LFS
chapter06/strippingagain.xml so it is not picked up every time by jhalfs.
However, we still need to address the issue on the valgrind page in BLFS.
Since you have not stripped, can you do a quick check of valgrind-3.12.0?
The only thing I needs is ./configure && make && make regtest.
There is a line that summarizes the tests. Mine looks like:
== 676 tests, 288 stderr failures, 66 stdout failures, 11 stderrB
failures, 13 stdoutB failures, 2 post failures ==
What do you get?
== 676 tests, 10 stderr failures, 3 stdout failures, 0 stderrB failures, 1
stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls (stdoutB)
memcheck/tests/leak_cpp_interior (stderr)
memcheck/tests/linux/getregset (stderr)
memcheck/tests/overlap (stderr)
memcheck/tests/sendmsg (stderr)
exp-sgcheck/tests/bad_percentify (stderr)
exp-sgcheck/tests/globalerr (stderr)
exp-sgcheck/tests/hackedbz2 (stdout)
exp-sgcheck/tests/hackedbz2 (stderr)
exp-sgcheck/tests/hsg (stdout)
exp-sgcheck/tests/hsg (stderr)
exp-sgcheck/tests/preen_invars (stdout)
exp-sgcheck/tests/preen_invars (stderr)
exp-sgcheck/tests/stackerr (stderr)
...checking makefile consistency
...checking header files and include directives
make: *** [Makefile:1338: regtest] Error 1
real 16m20.315s
user 12m45.859s
sys 0m32.149s
renodr [ /sources/valgrind-3.12.0 ]$
Those are my results...
Couldn't use a script as I haven't had the chance to make one yet. Sending
this from my laptop over a serial console.
OK, thanks. I can go from here. In several cases, I think the tests are
sensitive to things like glibc version. For instance, my failure for
memcheck/tests/overlap is:
--- overlap.stderr.exp 2016-10-21 05:37:39.000000000 -0500
+++ overlap.stderr.out 2016-10-31 17:05:24.323830401 -0500
@@ -1,11 +1,3 @@
-Source and destination overlap in memcpy(0x........, 0x........, 21)
- at 0x........: memcpy (vg_replace_strmem.c:...)
- by 0x........: main (overlap.c:40)
-
-Source and destination overlap in memcpy(0x........, 0x........, 21)
- at 0x........: memcpy (vg_replace_strmem.c:...)
- by 0x........: main (overlap.c:42)
-
Source and destination overlap in strncpy(0x........, 0x........, 21)
at 0x........: strncpy (vg_replace_strmem.c:...)
by 0x........: main (overlap.c:45)
That could easily be due to a different version of memcpy in the newer
glibc or just a different version of gcc.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
