Subject: bug#32559: closed (Re: coreutils-8.30: test sort-u-FMR fails after rebuild)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 30 Aug 2018 13:30:05 +0000

Your bug report

#32559: coreutils-8.30: test sort-u-FMR fails after rebuild

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
32559: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32559
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: coreutils-8.30: test sort-u-FMR fails after rebuild
From: Thomas Deutschmann <[email-masked]>
To: [email-masked]
Date: Thu, 30 Aug 2018 15:29:07 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Update:

This was caused by valgrind which was unable to read read-only PT_LOAD
segments and .rodata. In the end this wasn't triggered by glibc-2.27 but
by binutils which now defaults to "ld -z" (I didn't notice before
because bintuils was updated many weeks before so this was actually also
my first complete rebuild using the new binutils).

There's already a valgrind patch:
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=commit;h=64aa729bfae71561505a40c12755bd6b55bb3061

And a follow-up patch:
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=commit;h=e752326cc050803c3bcfde1f8606bead66ff9642

This bug report can be closed, thanks.

-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

Subject: coreutils-8.30: test sort-u-FMR fails after rebuild
From: Thomas Deutschmann <[email-masked]>
To: [email-masked]
Date: Tue, 28 Aug 2018 20:42:25 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hi,

after updating Gentoo's toolchain to GCC 8.2.0 and an entire world rebuild
test "misc/sort-u-FMR" is failing:

> + require_valgrind_
> + valgrind --error-exitcode=1 true
> + echo 0
> + printf '%0900d\n' 1
> + valgrind --error-exitcode=1 sort --p=1 -S32b -u in
> ==46265== Memcheck, a memory error detector
> ==46265== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==46265== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
> ==46265== Command: sort --p=1 -S32b -u in
> ==46265== 
> ==46265== Conditional jump or move depends on uninitialised value(s)
> ==46265==    at 0x49249CE: ??? (in /lib64/libc-2.27.so)
> ==46265==    by 0x48F4B31: ??? (in /lib64/libc-2.27.so)
> ==46265==    by 0x7FFFFFFFFFFFF: ???
> ==46265== 
> ==46265== Conditional jump or move depends on uninitialised value(s)
> ==46265==    at 0x491EE81: ??? (in /lib64/libc-2.27.so)
> ==46265==    by 0x1100D6: ??? (in /var/tmp/portage/sys-apps/coreutils-8.30/work/coreutils-8.30/src/sort)
> ==46265==    by 0x2F: ???
> ==46265==    by 0x402BCC2: ???
> ==46265==    by 0x30: ???
> ==46265==    by 0x5: ???
> ==46265==    by 0x402A36F: ???
> ==46265==    by 0x1FFEFF471F: ???
> ==46265==    by 0xA00000000000009: ???
> ==46265==    by 0x1FFEFF55A6: ???
> ==46265==    by 0x402B84F: ???
> ==46265==    by 0x402A7DF: ???
> ==46265== 
> ==46265== 
> ==46265== HEAP SUMMARY:
> ==46265==     in use at exit: 0 bytes in 0 blocks
> ==46265==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==46265== 
> ==46265== All heap blocks were freed -- no leaks are possible
> ==46265== 
> ==46265== For counts of detected and suppressed errors, rerun with: -v
> ==46265== Use --track-origins=yes to see where uninitialised values come from
> ==46265== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

Not sure what's causing the problem. On a system which was built using
gcc-7.3.0 test is passing if I only switch GCC to v8.2.0 and rebuild.

However, I was able to reproduce the test failure on 3 physical systems
after complete rebuild.

Complete logs are available at https://gist.github.com/Whissi/dde2960c1339a73d66c09613864488a5

-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5