[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
textutils "sort" patch
From: |
Michael L Maraist |
Subject: |
textutils "sort" patch |
Date: |
Sat, 9 Feb 2002 17:08:53 -0500 |
Starting somewhere after version 2.0.11, there was a change to at least the
src/sort.c program reguarding file operations. I first noticed this on Red
Hat 7.2 (which used 2.0.14).
The functional problem is:
ll /tmp/file*
-rw-rw-r-- 1 maraist maraist 0 Feb 9 15:23 /tmp/file1
-rw-rw-r-- 1 maraist maraist 6 Feb 8 13:30 /tmp/file2
sort -m /tmp/file1 /tmp/file2
Segmentation fault
More detailed analysis shows that if n files are provided, if any of 0 .. n-1
files are zero bytes in size, the system cores during merging.
The problem was that during the merge, a pass is made through all the files
reading the first line.. If a file is empty, the file-name is removed from
the list, BUT, nothing is done about the file-handles. This took me several
days to fix, but here's a patch based on version 2.0.19:
--- sort.c Sat Dec 1 12:29:26 2001
+++ sort_good.c Sat Feb 9 16:41:18 2002
@@ -1649,5 +1649,5 @@
/* Read initial lines from each input file. */
- for (i = 0; i < nfiles; ++i)
+ for (i = 0; i < nfiles; )
{
fps[i] = xfopen (files[i], "r");
@@ -1655,5 +1655,5 @@
MAX (merge_buffer_size, sort_size / nfiles));
/* If a file is empty, eliminate it from future consideration. */
- while (i < nfiles && !fillbuf (&buffer[i], fps[i], files[i]))
+ if (i < nfiles && !fillbuf (&buffer[i], fps[i], files[i]))
{
xfclose (fps[i], files[i]);
@@ -1662,4 +1662,6 @@
for (j = i; j < nfiles; ++j)
files[j] = files[j + 1];
+
+ continue; // redo this loop
}
if (i == nfiles)
@@ -1671,4 +1673,5 @@
base[i] = linelim - buffer[i].nlines;
}
+ i++;
}
sort_2.0.19.patch
Description: Text Data
- textutils "sort" patch,
Michael L Maraist <=