Bug 553193 - Locales are using large mmap-ed file /usr/lib/locale/locale-archive
Locales are using large mmap-ed file /usr/lib/locale/locale-archive
Status: CLOSED DUPLICATE of bug 541911
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Andreas Schwab
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-01-07 06:27 EST by Zdenek Kabelac
Modified: 2010-02-24 14:33 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-24 14:33:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Zdenek Kabelac 2010-01-07 06:27:57 EST
Description of problem:

For majority of application using mmap-ed file is actually not a problem as only tiny fraction of such file takes some memory (i.e.. typically in range of tens KB)

However problem is, when application wants to lock itself in memory.

Please check the original problem in bug 541911.  

If the application uses mlockall() then whole 100MB file (on my current rawhide distro) gets mmaped to memory and eats memory if some locales are set for such application.

Current solution for dmeventd is to either not setup locales inside the application or to switch them to plain C before application startup (as after all the binary itself is not really localized at this moment anyway)

But this effectively makes any application that wants to use mlockall() (for whatever reason) hardly 'localizable' - as locking 100MB of mostly junk into system memory is not really a good option in this case.

I'm not really sure what is the right solution here:

- maybe split the locale-archive to smaller files per language ?
- eventually at least support selectable locales for whole system, so the file has only locales which makes sense on given system - thus file is much much smaller ?
- or leave the current status and mark program that uses mlockall() non-localizable ?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. use dmeventd (device-mapper-event-1.02.38-2.fc12.x86_64) with some locales 
Actual results:
lots of resident memory taken by mlocked /usr/lib/locale/locale-archive

Expected results:

Additional info:
Comment 1 Andreas Schwab 2010-01-11 08:28:12 EST
Just remove that file, and setlocale will use the normal locale files.
Comment 2 Zdenek Kabelac 2010-01-11 08:41:12 EST
Well - as I mentioned above - easiest way is to startup the application with LANG=C. However this bugzilla is rather about some 'global' solution.

So are you proposing user should go to /usr/lib/locale and manually cleanup regenerated locale-archive wherever they notice the binary in memory uses to much memory ?
Comment 3 Juan Quintela 2010-02-24 14:29:26 EST
Any news on this problem?  I have to do

vgchange --monitor n
killall -9 dmeventd
LC_ALL=C vgchange --monitor y

If real problem is difficult to fix, it is easy to "workaround" it callingvgchange with LC_ALL=C everwhere.
Comment 4 Juan Quintela 2010-02-24 14:33:16 EST
Closing this bug as duplicated of #541911.

(Information on both was similar, and the other is older).  They refer to the same bug.

*** This bug has been marked as a duplicate of bug 541911 ***

Note You need to log in before you can comment on or make changes to this bug.