Bug 36539

Summary: sort goes into infinite loop with LC_ALL unset
Product: [Retired] Red Hat Linux Reporter: Greg Bailey <gbailey>
Component: glibcAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: high    
Version: 7.1CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-04-30 17:10:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test input file for sort failure none

Description Greg Bailey 2001-04-18 19:18:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.16-3 i686)


For specific input files (see attached file), the sort utility will go into
an infinite loop.  I first noticed this problem when sorting a 404MB file,
and managed to reproduce the problem with a smaller input file using the
"-S 4" option.  When I set LC_ALL=C, the problem does not appear.

Reproducible: Always
Steps to Reproduce:
1.  Execute "sort -S 4 test1 -o test1.output"   (program hangs--you can
examine temp files)
2.  Execute "LC_ALL=C sort -S 4 test1 -o test1.output"  (program is slow,
but finishes)
3.
	

Actual Results:  For step 1, nothing happens.
For step 2, the sort utility finishes as expected.

Expected Results:  The sort utility should finish successfully in both
cases.

I get the following when I interrupt the sort utility in gdb:

(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
0x400a33a9 in strcoll () from /lib/libc.so.6
(gdb) where
#0  0x400a33a9 in strcoll () from /lib/libc.so.6
#1  0x0804ef62 in memcoll (s1=0x8057000 "0-0-0-0-0-0-0-0-0-0.COM.",
s1len=25, 
    s2=0x8056f78 "00000-00000.COM.", s2len=17) at memcoll.c:44
#2  0x0804b73a in compare (a=0x8057060, b=0x8056fd8) at sort.c:1410
#3  0x0804be3e in mergefps (fps=0xbfffd6c0, nfps=16, ofp=0x8056e08, 
    output_file=0x8057280 "/tmp/sortnm2z9d") at sort.c:1583
#4  0x0804c7c4 in merge (files=0x8056980, nfiles=288, ofp=0x8056810, 
    output_file=0xbffffc04 "zxcv") at sort.c:1758
#5  0x0804cd45 in sort (files=0x80567ac, nfiles=-1, ofp=0x8056810, 
    output_file=0xbffffc04 "zxcv") at sort.c:1863
#6  0x0804e231 in main (argc=6, argv=0xbffffabc) at sort.c:2459
#7  0x4003a237 in __libc_start_main () from /lib/libc.so.6
(gdb) Quit

Comment 1 Greg Bailey 2001-04-18 19:20:26 UTC
Created attachment 15664 [details]
Test input file for sort failure

Comment 2 Helge Deller 2001-04-23 14:49:53 UTC
problem is still in textutils-2.0.13-1


Comment 3 Greg Bailey 2001-04-25 06:02:40 UTC
Seems to be a problem with the strcoll() function.

Consider the following program:

#include <stdio.h>
#include <string.h>
#include <locale.h>

int main( int argc, char *argv[] )
{
  char *t1 = "0-0-0-0-0-0-0-0-0-0.COM";
  char *t2 = "00000-00000.COM";

  setlocale( LC_ALL, "" );

  printf( "strcoll( \"%s\", \"%s\" ) = %d\n", t1, t2, strcoll( t1, t2 ) );
  printf( "strcoll( \"%s\", \"%s\" ) = %d\n", t2, t1, strcoll( t2, t1 ) );
}

Yields the output:

strcoll( "0-0-0-0-0-0-0-0-0-0.COM", "00000-00000.COM" ) = 1
strcoll( "00000-00000.COM", "0-0-0-0-0-0-0-0-0-0.COM" ) = 4

So when the sort utility is trying to merge the temporary files together in
mergefps(), it keeps swapping the same two entries corresponding to the test
samples above, as the first argument will ALWAYS be considered "greater" than
the second one, regardless of the order they are passed.

Will go digging through glibc unless someone else finds this one first...


Comment 4 Ulrich Drepper 2001-04-26 20:43:12 UTC
I've checed into the CVS archive a patch to fix this problem.  The fixed version
will be in 2.2.3.


Comment 5 Greg Bailey 2001-04-30 17:10:15 UTC
Can this be included if an errata RPM is made of glibc-2.2.2?  This affects lots
of other utilities in addition to "sort" like "ls", etc., etc.

Comment 6 Bernhard Rosenkraenzer 2001-05-18 10:32:31 UTC
It's fixed in rawhide and will be in the glibc errata we'll release in a while.