Debian Bug report logs - #286717
glibc: locale initialisation failure if cannot mmap locale.alias

Package: glibc; Maintainer for glibc is (unknown);

Reported by: James Youngman <jay@gnu.org>

Date: Tue, 21 Dec 2004 18:03:01 UTC

Severity: minor

Tags: l10n

Done: GOTO Masanori <gotom@debian.or.jp>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to James Youngman <jay@gnu.org>:
New Bug report received and forwarded. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: James Youngman <jay@gnu.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: glibc: locale initialisation failure if cannot mmap locale.alias
Date: Tue, 21 Dec 2004 17:46:16 +0000
Package: glibc
Severity: minor
Tags: l10n


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).



-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7-smp
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to GOTO Masanori <gotom@debian.or.jp>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 286717@bugs.debian.org (full text, mbox):

From: GOTO Masanori <gotom@debian.or.jp>
To: James Youngman <jay@gnu.org>, 286717@bugs.debian.org
Cc: Paul Eggert <eggert@CS.UCLA.EDU>
Subject: Re: Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias
Date: Fri, 14 Jan 2005 10:29:14 +0900
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




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Paul Eggert <eggert@CS.UCLA.EDU>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #15 received at 286717@bugs.debian.org (full text, mbox):

From: Paul Eggert <eggert@CS.UCLA.EDU>
To: GOTO Masanori <gotom@debian.or.jp>
Cc: James Youngman <jay@gnu.org>, 286717@bugs.debian.org
Subject: Re: Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias
Date: Fri, 14 Jan 2005 07:13:42 -0800
GOTO Masanori <gotom@debian.or.jp> writes:

> Thus, this is not bug of either glibc or coreutils.  Paul, how do you
> think about this?

Your analysis sounds good to me.  Thanks.



Reply sent to GOTO Masanori <gotom@debian.or.jp>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to James Youngman <jay@gnu.org>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #20 received at 286717-done@bugs.debian.org (full text, mbox):

From: GOTO Masanori <gotom@debian.or.jp>
To: Paul Eggert <eggert@CS.UCLA.EDU>, 286717-done@bugs.debian.org
Cc: GOTO Masanori <gotom@debian.or.jp>, James Youngman <jay@gnu.org>
Subject: Re: Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias
Date: Sat, 15 Jan 2005 20:25:30 +0900
At Fri, 14 Jan 2005 07:13:42 -0800,
Paul Eggert wrote:
> GOTO Masanori <gotom@debian.or.jp> writes:
> 
> > Thus, this is not bug of either glibc or coreutils.  Paul, how do you
> > think about this?
> 
> Your analysis sounds good to me.  Thanks.

Thanks, this report is treated as glibc default behaivor, I close it.

Regards,
-- gotom



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to James Youngman <jay@gnu.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 286717@bugs.debian.org (full text, mbox):

From: James Youngman <jay@gnu.org>
To: GOTO Masanori <gotom@debian.or.jp>
Cc: 286717@bugs.debian.org, Paul Eggert <eggert@CS.UCLA.EDU>
Subject: Re: Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias
Date: Fri, 14 Jan 2005 12:43:24 +0000
On Fri, Jan 14, 2005 at 10:29:14AM +0900, GOTO Masanori wrote:

> 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?

There is an argument that if sort cannot produce output which is
correctly sorted according to its locale settings, it should return
non-zero.  Presumably, it would need to test the return value of
setlocale() to do that, and setlocale() would need to return NULL in
this case.  Certainly, the POSIX definition of setlocale() does not
require that the implementation should return non-NULL in the case of
a failure.

James.





Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to James Youngman <jay@gnu.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 286717@bugs.debian.org (full text, mbox):

From: James Youngman <jay@gnu.org>
To: Paul Eggert <eggert@CS.UCLA.EDU>
Cc: GOTO Masanori <gotom@debian.or.jp>, 286717@bugs.debian.org
Subject: Re: Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias
Date: Fri, 14 Jan 2005 15:48:43 +0000
On Fri, Jan 14, 2005 at 07:13:42AM -0800, Paul Eggert wrote:
> GOTO Masanori <gotom@debian.or.jp> writes:
> 
> > Thus, this is not bug of either glibc or coreutils.  Paul, how do you
> > think about this?
> 
> Your analysis sounds good to me.  Thanks.

Taken as a whole though, the behaviour of the system does voliate the
principle of least surprise, which would imply that sort should either
produce the result that the documentation would imply given the
options that that the user selected, or should return a nonzero exit
status.

Having said this, I don't disagree with Masanori's analysis either.

Regards and thanks,
James.




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to GOTO Masanori <gotom@debian.or.jp>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 286717@bugs.debian.org (full text, mbox):

From: GOTO Masanori <gotom@debian.or.jp>
To: James Youngman <jay@gnu.org>
Cc: GOTO Masanori <gotom@debian.or.jp>, 286717@bugs.debian.org, Paul Eggert <eggert@CS.UCLA.EDU>
Subject: Re: Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias
Date: Mon, 17 Jan 2005 09:16:15 +0900
At Fri, 14 Jan 2005 12:43:24 +0000,
James Youngman wrote:
> On Fri, Jan 14, 2005 at 10:29:14AM +0900, GOTO Masanori wrote:
> 
> > 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?
> 
> There is an argument that if sort cannot produce output which is
> correctly sorted according to its locale settings, it should return
> non-zero.  Presumably, it would need to test the return value of
> setlocale() to do that, and setlocale() would need to return NULL in
> this case.

setlocale() in SUSv3 said:

    Setting all of the categories of the locale of the process is
    similar to successively setting each individual category of the
    locale of the process, except that all error checking is done
    before any actions are performed. To set all the categories of the
    locale of the process, setlocale() is invoked as:

    setlocale(LC_ALL, "");

    In this case, setlocale() shall first verify that the values of
    all the environment variables it needs according to the precedence
    rules (described in the Base Definitions volume of IEEE Std
    1003.1-2001, Chapter 8, Environment Variables) indicate supported
(1) locales. If the value of any of these environment variable
    searches yields a locale that is not supported (and non-null),
    setlocale() shall return a null pointer and the locale of the
(2) process shall not be changed. If all environment variables name
    supported locales, setlocale() shall proceed as if it had been
    called for each category, using the appropriate value from the
    associated environment variable or from the implementation-defined
    default if there is no such value.

If the locale name search is succeeded (condition (1) is not matched),
setlocale() could be succeeded using the implementation defined
default - glibc uses C (condition (2) is matched).  One drawback of
setlocale() is it does not return any error number - we cannot deliver
any error type for example ENOMEM.  We don't distinguish between the
target locale missing and error condition.

Regards,
-- gotom




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Paul Eggert <eggert@CS.UCLA.EDU>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 286717@bugs.debian.org (full text, mbox):

From: Paul Eggert <eggert@CS.UCLA.EDU>
To: 286717@bugs.debian.org
Subject: Re: glr bison default actions broken
Date: Tue, 25 Jan 2005 12:19:06 -0800
I cannot reproduce the bug in Bison 2.0 (the current stable release).
It has many improvements to glr.c in this area, and for now I'm going
to assume that they have fixed the bug.

You can get it here:

ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <drow@false.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 286717@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <drow@false.org>
To: Paul Eggert <eggert@CS.UCLA.EDU>, 286717@bugs.debian.org
Subject: Re: Bug#286717: glr bison default actions broken
Date: Tue, 25 Jan 2005 15:46:28 -0500
On Tue, Jan 25, 2005 at 12:19:06PM -0800, Paul Eggert wrote:
> I cannot reproduce the bug in Bison 2.0 (the current stable release).
> It has many improvements to glr.c in this area, and for now I'm going
> to assume that they have fixed the bug.
> 
> You can get it here:
> 
> ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz

Hi Paul,

Did you mean to send this to a different bug report?

-- 
Daniel Jacobowitz



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#286717; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Paul Eggert <eggert@CS.UCLA.EDU>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 286717@bugs.debian.org (full text, mbox):

From: Paul Eggert <eggert@CS.UCLA.EDU>
To: Daniel Jacobowitz <drow@false.org>
Cc: 286717@bugs.debian.org
Subject: Re: Bug#286717: glr bison default actions broken
Date: Tue, 25 Jan 2005 15:40:20 -0800
Daniel Jacobowitz <drow@false.org> writes:

> Did you mean to send this to a different bug report?

Oops, yes, sorry, it should have been Debian bug 195946.  Sorry about
the cut and paste error.  I'll resubmit it with the right bug number.



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 17:04:01 2014; Machine Name: beach.debian.org

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