bug#12453: failed test suite on 64-bit debian squeeze

[Jim Meyering]

Laurence Maddox wrote:
> I am in chapter 5 of Linux from Scratch, and the coreutils test suite
> fails with a message instructing me to file a bug report to you. It
> also mentions a log file, which I have included.
>
> My system is a corei7 running a debian squeeze ramboot live-cd. I have
> sufficient memory and disk space.
>
> ==============================================
>    GNU coreutils 8.19: tests/test-suite.log
> ==============================================
>
> # TOTAL: 491
> # PASS:  415
> # SKIP:  75
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
...
> FAIL: misc/sort-u-FMR
> =====================
...
> sort (GNU coreutils) 8.19
...
> + require_valgrind_
> + valgrind --help
> + echo 0
> + printf '%0900d\n' 1
> + valgrind --error-exitcode=1 sort --p=1 -S32b -u in
> ==26580== Memcheck, a memory error detector
> ==26580== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
> ==26580== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for 
> copyright info
> ==26580== Command: sort --p=1 -S32b -u in
> ==26580==
> ==26580== Conditional jump or move depends on uninitialised value(s)
> ==26580==    at 0x4017676: index (strchr.S:55)
> ==26580==    by 0x4007752: expand_dynamic_string_token (dl-load.c:430)
> ==26580==    by 0x4007FC4: _dl_map_object (dl-load.c:2277)
> ==26580==    by 0x40016ED: map_doit (rtld.c:632)
> ==26580==    by 0x400E535: _dl_catch_error (dl-error.c:177)
> ==26580==    by 0x4000FFD: do_preload (rtld.c:821)
> ==26580==    by 0x40043B6: dl_main (rtld.c:1725)
> ==26580==    by 0x401490D: _dl_sysdep_start (dl-sysdep.c:242)
> ==26580==    by 0x4004C6D: _dl_start (rtld.c:337)
> ==26580==    by 0x4001507: ??? (in /mnt/lfs/tools/lib/ld-2.16.so)
> ==26580==    by 0x4: ???
> ==26580==    by 0x7FEFFBC12: ???
> ==26580==
> ==26580== Conditional jump or move depends on uninitialised value(s)
> ==26580==    at 0x401767B: index (strchr.S:58)
> ==26580==    by 0x4007752: expand_dynamic_string_token (dl-load.c:430)
> ==26580==    by 0x4007FC4: _dl_map_object (dl-load.c:2277)
> ==26580==    by 0x40016ED: map_doit (rtld.c:632)
> ==26580==    by 0x400E535: _dl_catch_error (dl-error.c:177)
> ==26580==    by 0x4000FFD: do_preload (rtld.c:821)
> ==26580==    by 0x40043B6: dl_main (rtld.c:1725)
> ==26580==    by 0x401490D: _dl_sysdep_start (dl-sysdep.c:242)
> ==26580==    by 0x4004C6D: _dl_start (rtld.c:337)
> ==26580==    by 0x4001507: ??? (in /mnt/lfs/tools/lib/ld-2.16.so)
> ==26580==    by 0x4: ???
> ==26580==    by 0x7FEFFBC12: ???
> ==26580==
> --26580-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a
>
> valgrind: m_debuginfo/readdwarf.c:2329 (copy_convert_CfiExpr_tree): Assertion 
> 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
> ==26580==    at 0x3802B0A7: report_and_quit (m_libcassert.c:191)
> ==26580==    by 0x3802B2E0: vgPlain_assert_fail (m_libcassert.c:265)
> ==26580==    by 0x3809C7BF: copy_convert_CfiExpr_tree (readdwarf.c:2329)
> ==26580==    by 0x3809CB05: summarise_context (readdwarf.c:2129)
> ==26580==    by 0x3809F1BD: run_CF_instructions (readdwarf.c:3541)
> ==26580==    by 0x380A0DDC: vgModuleLocal_read_callframe_info_dwarf3 
> (readdwarf.c:4079)
> ==26580==    by 0x38058A85: vgModuleLocal_read_elf_debug_info (readelf.c:2077)
> ==26580==    by 0x38054229: vgPlain_di_notify_mmap (debuginfo.c:818)
> ==26580==    by 0x38071689: vgModuleLocal_generic_PRE_sys_mmap 
> (syswrap-generic.c:2039)
> ==26580==    by 0x38092BC9: vgSysWrap_amd64_linux_sys_mmap_before 
> (syswrap-amd64-linux.c:995)
> ==26580==    by 0x38067EE7: vgPlain_client_syscall (syswrap-main.c:1442)
> ==26580==    by 0x38064A4D: handle_syscall (scheduler.c:895)
> ==26580==    by 0x380658B9: vgPlain_scheduler (scheduler.c:1091)
> ==26580==    by 0x3808F194: run_a_thread_NORETURN (syswrap-linux.c:94)
>
> sched status:
>   running_tid=1
>
> Thread 1: status = VgTs_Runnable
> ==26580==    at 0x401721A: mmap (syscall-template.S:81)
> ==26580==    by 0x4006757: _dl_map_object_from_fd (dl-load.c:1333)
> ==26580==    by 0x4008054: _dl_map_object (dl-load.c:2344)
> ==26580==    by 0x400C781: openaux (dl-deps.c:63)
> ==26580==    by 0x400E535: _dl_catch_error (dl-error.c:177)
> ==26580==    by 0x400C9C6: _dl_map_object_deps (dl-deps.c:256)
> ==26580==    by 0x40030C8: dl_main (rtld.c:1834)
> ==26580==    by 0x401490D: _dl_sysdep_start (dl-sysdep.c:242)
> ==26580==    by 0x4004C6D: _dl_start (rtld.c:337)
> ==26580==    by 0x4001507: ??? (in /mnt/lfs/tools/lib/ld-2.16.so)
> ==26580==    by 0x4: ???
> ==26580==    by 0x7FEFFBC12: ???
> ==26580==    by 0x7FEFFBC17: ???
> ==26580==    by 0x7FEFFBC1D: ???
> ==26580==    by 0x7FEFFBC23: ???
> ==26580==    by 0x7FEFFBC26: ???

Thank you for reporting that.
At first glance, that failing assertion seems due to a bug in your
system's version of valgrind.  I don't immediately see a clean way
to work around it.  Sure, the dirty way would be to search for this
line:

> valgrind: m_debuginfo/readdwarf.c:2329 (copy_convert_CfiExpr_tree): Assertion 
> 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.

and when found, skip the test, saying "your version of valgrind is
inadequate".  In any case, this failure does not mean sort has a
problem.  Just valgrind, and maybe the test itself, for relying
on valgrind.