bug#7489: [coreutils] over aggressive threads in sort

[DJ Lucas]

On 11/26/2010 05:24 PM, Paul Eggert wrote:
> Thanks for the bug report.  Unfortunately,
> I cannot reproduce the problem with coreutils 8.7, either on
> RHEL 5.5 x86-64 or on Ubuntu 10.10 x86.
> 
> Which version of coreutils are you running?  


8.7.  Haven't tested on 8.6 or 8.5. 8.4 worked correctly, but that was
expected since I can get around it if not running in multiple threads.

> And on what
> platform?  

LFS 32bit on Athlon II 250 (64bit dual core CPU/hardware). gcc-4.5.1,
glibc-2.12.1, binutils-2.20.1.

> How did you build it?

Basic CMMI --prefix=/usr. Built both with and without i18n RH patch and
Linux only uname patches.

> 
> Can you reproduce it with --parallel=2?  If not, which value
> of --parallel is needed?

Yes, it is reproducible with --parallel=2.  Seems this is a difficult
one to track down. So far we've only confirmed that it happens in
multibyte locales, with 32bit build on 64bit multi-core hardware, and
only from stdin. Works fine if the file is passed as an argument to
sort. Haven't confirmed 64bit build had multibyte yet, but the error did
not occur on the report from that user. Setting LANG/LC_ALL to C or
POSIX works around it, as well as --parallel=1. I've added a quick and
really ugly workaround in the interim so that I can continue and get
some work done (using getenv("LC_COLLATE"), and testing only against !=
POSIX and != C, setting nthreads=1). Confirmed that the correct encoding
is displayed with --debug with the workaround in place.

If you have a similar setup laying around (32bit installation on 64bit
multi-core hardware), try
cat bigfile.txt | LANG=en_US.UTF-8 sort -u (or similar)

> 
> If this is coreutils 8.7, can you get a core dump and a GDB
> backtrace?
> 

Sure, give me a bit, but looks like Pádraig Brady beat me to it.

-- DJ Lucas

-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.