Re: "make check" failure with sort-compress on OSF and Linux

[Jim Meyering]

Dan Hipschman <address@hidden> wrote:
> On Fri, Feb 23, 2007 at 12:57:49AM +0100, Jim Meyering wrote:
>> Even so, sort needs a better fall-back position for when it fails to
>> fork a decompression process (failing to start a compression process
>> isn't a big problem).  If it can't fork the process, it should simply
>> revert to decompressing each stream as it reads it.  This is possible
>> (easy, even) when using gzip or bzip2, and part of the reason I want to
>> limit the list of compressors to programs like those that provide the
>> required procedural interfaces.
>
> Last resort, if you don't have the time to fix it, just don't make
> compression the default for the upcoming stable release.  I.e., leave
> the option in, but require it to be explicitly requested.  I'd love to
> help, but I'm not sure how long it will take me to do this with my
> current schedule.

Yep, that's what I'm going to do.
I was just poking around with gdb, started like this:

  seq -w 10000 > exp
  gdb --args ./sort -S 1k exp

my jaw hit the floor when I saw the 500+ gzip zombies
left hanging while I'm at a breakpoint in merge.