Red Hat Bugzilla – Bug 553193
Locales are using large mmap-ed file /usr/lib/locale/locale-archive
Last modified: 2010-02-24 14:33:16 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):
Steps to Reproduce:
1. use dmeventd (device-mapper-event-1.02.38-2.fc12.x86_64) with some locales
lots of resident memory taken by mlocked /usr/lib/locale/locale-archive
Just remove that file, and setlocale will use the normal locale files.
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 ?
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.
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 ***