I've downgraded to version: coreutils-8.5-10.fc15.x86_64
which seem to be the last properly working release.


Release coreutils-8.6-1.fc15.x86_64  is the first broken one for F15.

One more thing - file is not just common file (Zdenek is able to reproduce on x86_64 T61 machine it with /var/log/messages , but not with e.g. /etc/passwd) ... I was not able to reproduce on my i686 T60 machine, though ...

Does spin forever?
If not, how much longer does sort-8.7 take than sort-8.5?
Does adding the --parallel=1 option change things?

Yes, it's spinning forever as long as it waits for 'less' to print more text.

i.e. a workaround is this:   sort file | tee /dev/null | less
though it's not really practical....

And positive seems to be adding  '--parallel=1' at it fixes the problem.

Drats. I'd been worried about that. Pity my laptop isn't multicore :(
http://lists.gnu.org/archive/html/bug-gnulib/2010-09/msg00361.html

You could try changing spinlocks to mutexes with:
ftp://ftp.gnu.org/gnu/coreutils/coreutils-8.7.tar.xz
and configure with HAVE_PTHREAD_SPINLOCK_T undefined.
Or you could manually put the following at the top of src/sort.c:


typedef pthread_mutex_t pthread_spinlock_t;

static inline int
pthread_spin_init (pthread_spinlock_t *lock, int pshared)
{
  return pthread_mutex_init (lock, NULL);
}

static inline int
pthread_spin_destroy (pthread_spinlock_t *lock)
{
  return pthread_mutex_destroy (lock);
}

static inline int
pthread_spin_lock (pthread_spinlock_t *lock)
{
  return pthread_mutex_lock (lock);
}

static inline int
pthread_spin_trylock (pthread_spinlock_t *lock)
{
  return pthread_mutex_trylock (lock);
}

static inline int
pthread_spin_unlock (pthread_spinlock_t *lock)
{
  return pthread_mutex_unlock (lock);
}

Here is actual backtrace from the spinlocked thread from current 
coreutils-8.7-2.fc15.x86_64


(gdb) bt
#0  0x00007fd4275cd425 in ?? () from /lib64/libpthread.so.0
#1  0x0000000000404fde in lock_node (node=<value optimized out>) at sort.c:3766
#2  update_parent (queue=0x7fff8098f2a0, merged=<value optimized out>, node=0x7fd3db4d5da0) at sort.c:3943
#3  merge_loop (temp_output=0x0, tfp=0x7fd4275ba8c0, total_lines=257991, queue=0x7fff8098f2a0) at sort.c:3977
#4  sortlines (lines=<value optimized out>, dest=<value optimized out>, nthreads=140735350895272, total_lines=257991, parent=<value optimized out>, 
    lo_child=<value optimized out>, merge_queue=0x7fff8098f2a0, tfp=0x7fd4275ba8c0, temp_output=0x0) at sort.c:4088
#5  0x00000000004054ab in sortlines_thread (data=<value optimized out>) at sort.c:4011
#6  0x00007fd4275c7d5b in start_thread () from /lib64/libpthread.so.0
#7  0x00007fd427301aad in clone () from /lib64/libc.so.6

btw - it's very nicely visible i.e. on quad core that even though you make a real time processing fast -  user time is actually much higher.
(i.e. on larger file    22s real&user  single threaded ->  13/47s multi core solution - so in effect code takes twice as much CPU at current implementation.)

I think it is not a good plan to 'randomly' replace  spinlock with mutex - that's not how pthread works - I would expect some conditional waits somewhere.

Oh and btw. I really don't understand how such patch could have been acked....

> Oh and btw. I really don't understand how such patch could have been acked

Mea culpa. I've no dedicated multicore hardware, but mainly no time.
Full performance testing is on my todo list (you could help here :))
http://lists.gnu.org/archive/html/bug-coreutils/2010-07/msg00144.html
I thought it better to release early to get varied testing,
given I was happy that it was functionally correct.

coreutils-8.8-1.fc15 with various upstream fixes for parallel sorting built, closing RAWHIDE.