From f3c584d1e08646704cb46f4e5b6afc4afef3f70a Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 16 Dec 2010 00:03:29 -0800 Subject: sort: don't dump core when merging from input twice * NEWS: Document this. * src/sort.c (avoid_trashing_input): The previous fix to this function didn't fix all the problems with this code. Replace it with something simpler: just copy the input file. This doesn't change the number of files, so return void instead of the updated file count. Caller changed. * tests/misc/sort-merge-fdlimit: Test for the bug. --- tests/misc/sort-merge-fdlimit | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'tests') diff --git a/tests/misc/sort-merge-fdlimit b/tests/misc/sort-merge-fdlimit index 1ed50952f..b0ab71cec 100755 --- a/tests/misc/sort-merge-fdlimit +++ b/tests/misc/sort-merge-fdlimit @@ -50,4 +50,24 @@ for randsource in '' --random-source=some-data; do || ! grep "open failed" err/merge-random-err) || fail=1 done +# 'sort -m' should work in a limited file descriptor +# environment when the output is repeatedly one of its inputs. +# In coreutils 8.7 and earlier, 'sort' would dump core on this test. +# +# This test uses 'exec' to redirect file descriptors rather than +# ordinary redirection on the 'sort' command. This is intended to +# work around bugs in OpenBSD /bin/sh, and some other sh variants, +# that squirrel away file descriptors before closing them; see +# . +# This test finds the bug only with shells that do not close FDs on +# exec, and will miss the bug (if present) on other shells, but it's +# not easy to fix this without running afoul of the OpenBSD-like sh bugs. +(seq 6 && echo 6) >exp || fail=1 +echo 6 >out || fail=1 +(exec 3<&- 4<&- 5<&- 6