GNU bug report logs - #7489
[coreutils] over aggressive threads in sort

Previous Next

Full log

Message #86 received at 7489 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Chen Guo <chen.guo.0625 <at> gmail.com>
Cc: DJ Lucas <dj <at> linuxfromscratch.org>, 7489 <at> debbugs.gnu.org, coreutils <at> gnu.org
Subject: Re: bug#7489: [coreutils] over aggressive threads in sort
Date: Thu, 02 Dec 2010 09:48:56 -0800

On 12/02/10 02:22, Chen Guo wrote:
> On Mon, Nov 29, 2010 at 11:16 AM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>>  (for i in $(seq 12); do read line; echo $i; sleep .1; done
>>  cat > /dev/null) < fifo &
>>  (ulimit -t 1; ./sort in > fifo \
>>  || echo killed via $(env kill -l $(expr $? - 128)))
> 
> I ran this 10 times or so on an i7 and couldn't trigger anything. Is
> seq 12 supposed to vary depending on the number of cores?

I imagine it does.  It's timing-dependent; I can't always reproduce
it on my test host (Intel Xeon E5620 2.4 GHz).

I just now realized that the above doesn't say what "in" is; it's
the output of "seq 100000".

Also, it may help to use an explicit --parallel=2 or whatever.

What happens if you do the following with the latest git version
(savannah's back up, by the way)?

   cd tests && make check TESTS=misc/sort-spinlock-abuse

This gets an XFAIL fairly reliably on my test host.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.