GNU bug report logs - #7652
coreutils snapshot time?

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-coreutils <at> gnu.org
Subject: Re: coreutils snapshot time?
Date: Thu, 16 Dec 2010 09:21:12 +0100

I'd like to make a snapshot soon, and asked Paul how his sort
work was coming.  He replied:

> 1 There's still a bug with sort -m -o f f; it can dump core
>   despite my recent patch there.  I have a fix for this and
>   will push it (+ test case) shortly.
>
> 2 After further thinking about it, I now realize why there
>   used to be a reference count for process-IDs.  It's possible
>   that two or more temp files are associated with the same process ID.
>   The old code was designed to detect this, but I don't think it worked.
>   The new code that I checked in a couple of days ago was not designed
>   to detect this (I considered the scenario, but incorrectly concluded
>   that it wouldn't lead to a problem), and I now know it doesn't work.
>   I have a fix in mind and will work on it next.
>
> 3 The sort --compress/hang problem.  It's conceivable this is the
>   same bug as (2), but most likely it's different.
>
> None of these bugs are pressing: (1) has been there for ages
> and (2) and (3) are present only if --compress is used, which
> isn't common.  So I don't think it matters much whether these
> fixes are in the next version.  I'd like (1) to go in at least,
> and I think I can fix (2) in a day or two; dunno about (3).

Thanks!

I'll wait a little, in case a fix for (2) is forthcoming.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.