sort utility goes berzerk (x86_64)

Tue Nov 28 14:54:00 GMT 2017

On 2017-11-28 14:37, Doug Henderson wrote:

>>> On Nov 28 08:21, Houder wrote:
>>>> On 2017-11-25 14:23, Houder wrote:
>>>> > Hi,
>>>> >
>>>> > Anyone seeing this as well? sort goes berzerk on my system when piped
>>>> > into
>>>> > head (or less) when it is fed with a 'specially prepared' input file.
>>>> >
>>>> >  - only happens on x86_64
>>>> >  - does not happen for 'LC_COLLATE=C sort tt | head'
>>>> >
>>>> > 'specially prepared' input file? (see bottom of post).
>>>> Anyone ** NOT ** seeing this?

> Q0. What is the value of PATH reported by "printenv PATH"? Just to
> verify it matches the cygcheck reported path, and to confirm that
> cygwin directories proceed windows folders.

64-@@ printenv PATH

> Q1. What is output of "which -a sort"? Is there only one sort in the 
> path?

64-@@ which -a sort

> Q2. What is output of "sort --version"? Confirm if it is "sort (GNU
> coreutils) 8.26".

64-@@ sort --version
sort (GNU coreutils) 8.26
Packaged by Cygwin (8.26-2)

64-@@ /usr/bin/sort --version
sort (GNU coreutils) 8.26
Packaged by Cygwin (8.26-2)

> Q3. What happens when you run "sort --check FILE" on a problem file?

64-@@ sort -c tt | head
64-@@ echo $?

> Q4. After you kill a hung sort, are there files left over in /tmp? I
> am wondering if the problem files are too big to do an in-core sort,
> and something goes wrong when it switches to a temp file sort, but not
> for smaller or larger input files where it correctly predicts which
> type of sort it needs to do. Possibly using the "--buffer-size=N"
> option will change the behavior, making smaller input files fail and
> failing ones work.

Never noticed any file in /tmp, /usr/tmp and /var/tmp, both while sort
was still running, and after I killed it.

I will experiment with --buffer-size=N


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list