On 12/05/10 03:21, Jim Meyering wrote: > seq -w 200000 > exp && tac exp > in > PATH=.:$PATH ./sort --compress-program=dzip -S 1k in > out > > That gets stuck in waitpid (from sort.c's reap), waiting for a > dzip invocation that appears will never terminate. This is also > on that same 4-core system, and is relatively easy to reproduce, > so it should be easy to identify the offending change, but I'm > out of time, now. >
I've verified this bug. It occurs regardless of whether the December 3 changes are applied, so it looks like it was an earlier change. I've also verified that it occurs with --parallel=1 so it seems unlikely it would be thread-related. What happens is that 'sort' creates a pipe to a compressor but then never closes the pipe. When it waits for the compressor to finish there is an obvious deadlock. I'll see if I can track it down, but my guess it's somewhere in the compressor/decompressor code. It's doing some lazy evaluation and I wouldn't be surprised if that goes haywire in some cases. I'd guess there's also a bug in the thread code too, having to do with your core dump (and Chen's; could be two bugs).
