bug#55212: GNU Linux "sort -g" can hang indefinitely when run on standard input if NaNs are involved

[Paul Eggert]

On 5/10/22 12:08, coreut...@tlinx.org wrote:

    Unless there is some magic about -n1238095,


The test is random and there's no magic, just luck. The larger the 
random test, the more likely you'll run into the unlucky situation where 
the unpatched 'sort' infloops.

bug#55212: GNU Linux "sort -g" can hang indefinitely when run on standard input if NaNs are involved

[coreutils]

On 2022/05/01 10:16, Giulio Genovese wrote:

As explained here
,
when running "sort -g" from standard input, if NaNs are involved, this can
cause "sort -g" to hang indefinitely while consuming 100% of the CPU. This
seems to be system dependent. I cannot reproduce the bug on a RHEL7
machine. However, multiple users seem to be able to reproduce the bug. The
following command can provoke the bug:

yes nan | head -n128095 | timeout 5 sort -g
  


   Unless there is some magic about -n1238095,
Using a smaller number like -n1 or -n12 both terminate after 1 or 12 lines.
I wasn't willing to wait for 1.2M lines being output, though the -n128085
case did start to output until I terminated it -- which would seem to
indicate that the sort had finished and was dumping its output.  I.e.
no indefinite hang.

sort from 8.26.18-5e871
from suse old tumbleweed (out of sync - no longer updates)

bug#33123: ls: add case-sensitive --color option

[Pádraig Brady]

On 10/05/2022 09:45, Mikael Magnusson wrote:

Hi,

In bug #9086 [1] there was a lot of good discussion about case
insensitive matching for dircolors. This was all then summarily
ignored in [2] which made the behaviour unconditional. This breaks
coloring of uppercase files that should have a different color from
lowercase files, for example .C which is a c++ source file, not a c
source file. And as mentioned in [1] it is also very useful to notice
incorrectly (eg uppercase extension files) quickly by them being
white, so you can fix them.

I'm not sure if the suggestion in this bug (33123) is good though;
since ls --color=auto-case will just error on older releases, you
can't easily sync your aliases. Unfortunately ls also ignores all of
LS_COLORS if it contains any unknown values (why??) so we can't add a
"CS" field there for case sensitiveness either (unless there's some
extra options field already I don't know about?).

If anyone has some ideas I would be happy to produce a patch (assuming
you don't need copyright assignment).

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9086
[2] https://lists.gnu.org/archive/html/coreutils/2018-06/msg00011.html


Thanks for taking the time to tie all these threads together.

Yes we forgot about [1] when implementing [2].

The ideas in [1] are sound. I.e. we shouldn't need a new option.
We just need to honor any capitalized extension entries,
and fall back to case insensitive for lower case extensions.
We do need to be cognizant of performance though.
We could sort the list of extensions, which would auto give
precedence to capitalized entries, and we might also use that
sorting to break out of the match loop early.

I'll look at this soon.

cheers,
Pádraig

bug#33123: ls: add case-sensitive --color option

[Mikael Magnusson]

Hi,

In bug #9086 [1] there was a lot of good discussion about case
insensitive matching for dircolors. This was all then summarily
ignored in [2] which made the behaviour unconditional. This breaks
coloring of uppercase files that should have a different color from
lowercase files, for example .C which is a c++ source file, not a c
source file. And as mentioned in [1] it is also very useful to notice
incorrectly (eg uppercase extension files) quickly by them being
white, so you can fix them.

I'm not sure if the suggestion in this bug (33123) is good though;
since ls --color=auto-case will just error on older releases, you
can't easily sync your aliases. Unfortunately ls also ignores all of
LS_COLORS if it contains any unknown values (why??) so we can't add a
"CS" field there for case sensitiveness either (unless there's some
extra options field already I don't know about?).

If anyone has some ideas I would be happy to produce a patch (assuming
you don't need copyright assignment).

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9086
[2] https://lists.gnu.org/archive/html/coreutils/2018-06/msg00011.html

-- 
Mikael Magnusson