bug#9307: sort crashes on big files

[Michael Stahn]

Hi all,

Calling sort -u -S 1G file.txt > output.txt from coreutils-8.7 crashes
sort. Increasing memory size doesn't help. The size of file.txt is
approximately 1G. The program was called with other text-files with similar
size and it crashes only in some cases (same file every time). I cant upload it
here because of the size, but it's just a plain textfile.
This bug only seems to happen if sort is called with "-u" option.

Steps to Reproduce:
1. call sort -u -S 1G file.txt > output.txt with a min 1G plaintext-file

Actual Results:
Sort crashes with "Killed" or "Segmenation fault", depending on the file. Also
some sortXXXX-files in /tmp ARE NOT deleted if sort crashes! Your disk will
become clobbered with trash in a very short time when sorting big files.

Backtrace (without debug symbols):

Starting program: /bin/sort -u -S 1G bigfile.txt
[Thread debugging using libthread_db enabled]
[New Thread 0x77af2b70 (LWP 7473)]
[Thread 0x77af2b70 (LWP 7473) exited]
[New Thread 0x77af2b70 (LWP 7828)]
[Thread 0x77af2b70 (LWP 7828) exited]
[New Thread 0x77af2b70 (LWP 8248)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77af2b70 (LWP 8248)]
0x0804c3a3 in ?? ()
#0  0x0804c3a3 in ?? ()
No symbol table info available.
#1  0x0804c65d in ?? ()
No symbol table info available.
#2  0x0804d4c4 in ?? ()
No symbol table info available.
#3  0x0804da61 in ?? ()
No symbol table info available.
#4  0xb7fb4d23 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0xb7f22bfe in clone () from /lib/libc.so.6
No symbol table info available.