I've tried coreutils-5.0.91-r{2,3,4}, so this problem seems to have been introduced in -r3. Running sort -g on a file larger than ~25MB causes sort to use up all memory then either a) crash the system or b) cause the OOM killer to kill it. Reproducible: Always Steps to Reproduce: 1. Run sort -g on a large data set, 25MB or larger. Problem is reproduceable in valid sorts ("<number> ..." formatted lines) and non-valid (I tested on a large tar.gz) Actual Results: Sort quickly grows consuming all physical memory, draining cache and buffers, then draining swap file. System becomes mostly unresponsive, the oom killer kills sort (and possible another program (xmms in my case)), and life goes on. Expected Results: Grown to a sane size (seems to be ~40MB-100MB) and sorted the results. Gentoo Base System version 1.4.3.12 Portage 2.0.50_pre16 (default-x86-1.4, gcc-3.3.2, glibc-2.2.5-r2,2.3.3_pre20031222-r0, 2.6.0-gentoo-r2) ================================================================= System uname: 2.6.0-gentoo-r2 i686 AMD Athlon(tm) Processor ccache version 2.2 [enabled] Autoconf: sys-devel/autoconf-2.58,sys-devel/autoconf-2.52d-r1,sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.7.8 ACCEPT_KEYWORDS="x86" AUTOCLEAN="no" CFLAGS="-march=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox userpriv" GENTOO_MIRRORS="http://gentoo.seren.com/gentoo ftp://mirrors.tds.net/gentoo http://mirrors.tds.net/gentoo ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/mnt/large/portage/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xaw3d aalib acl apm arts avi berkdb bonobo cdr crypt cups dga directfb doc dvd dvdr encode esd evo foomaticdb gdbm ggi gif gnome gpm gtk gtk2 gtkhtml guile imlib jpeg kde ldap libg++ libwww mad mikmod motif mozilla mpeg mysql nas ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline ruby samba scanner sdl slang spell sse ssl svga tcltk tcpd tetex truetype usb x86 xinerama xml2 xmms xv zlib"
can you reproduce this in coreutils-5.2.0? (about to check into portage)
Yes, it occurs in 5.2.0 too.
I'm not able to either reproduce or find anyone who can troubleshoot. Not sure what to do about this one, to be honest. I'm assuming 5.2.1 still displays this behaviour? qube, can you edit the coreutils-5.2.1 ebuild and remove all the epatch lines (comment out the entire src_unpack function, come to think of it), and see if vanilla coreutils suffers?
Right, coreutils-5.2.1's sort borks as well with all the patches. Without the patches, coreutils-5.2.1's sort seems to behave sanely.
Sven, wanna have a look see?
Created attachment 37910 [details, diff] sort.c.patch There ya go Seemant.
The patch seems to fix it for me for both valid and invalid files.
thanks Sven. fixed in -r2
*** Bug 64222 has been marked as a duplicate of this bug. ***
