Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias
Hi,
At Tue, 21 Dec 2004 17:46:16 +0000,
James Youngman wrote:
> If VM is limited (e.g. with ulimit -v 1800), the output of "sort" fails
> the "sort -c" check if $LANG is set; the upstream coreutils maintainer
> (Paul Eggert) alleges that this may be due to a glibc set-up problem or
> perhaps a bug.
>
> Paul writes:
>
> I suspect this is a problem with your GNU C library setup, not with
> "sort" per se. glibc attempts to mmap the locale-archive file as a
> performance speedup, and falls back on the locale.alias file if the
> locale-archive can't be mmapped (which in this case it can't, because
> you're low on memory). Perhaps these two sources of locale information
> are inconsistent on your host. Or possibly you have found a glibc bug.
> Most likely you can work around the bug by setting LC_ALL="C" in your
> environment
>
> More details can be found at
> http://savannah.gnu.org/bugs/?func=detailitem&item_id=11004, which is
> the initial bug report against coreutils. This includes a typescript
> demonstrating the problem, and strace output of both the failing case
> and the case where there is no problem (i.e. where VM is not limited).
I think the point is if VM is limited, the first sort works as LANG=C:
( ulimit -v 1800 >/dev/null ; sort < testfile ) | sort -c
Thus, it should work:
( ulimit -v 1800 >/dev/null ; sort < testfile ) | LANG=C sort -c
Looking at the first sort with ltrace command, setlocale() in sort
returns as "C" locale. The current glibc works as follows: when the
2nd argument of setlocale() is "", and setting LC_ALL is failed, we
should try to the next environment variable like LANG. But memory is
limited, so all environment variable is not treated, then it falls
back to C locale. So the return value becomes "C". Using "" is
implementation bahavior, so I think the current behavior is not wrong.
Thus, this is not bug of either glibc or coreutils. Paul, how do you
think about this?
Regards,
-- gotom
Reply to: