[perl #134264] switching locales no longer invalidates gettexttranslation cache since 5.28

On Sat, 06 Jul 2019 08:44:13 -0700, public@khwilliamson.com wrote:
> On 7/5/19 10:18 PM, Karl Williamson wrote:
> > On 7/5/19 1:00 AM, Niko Tyni wrote:
> >> On Thu, Jul 04, 2019 at 12:39:05PM -0700, karl williamson via RT
> >> wrote:
> >>> On 7/4/19 12:01 PM, Niko Tyni (via RT) wrote:
> >>
> >>>> As discussed in https://bugs.debian.org/931139 and
> >>>>  https://bugs.debian.org/924657 glibc has a cache of already
> >>>> loaded
> >>>> gettext
> >>>> translations that gets invalidated in setlocale(3),
> >>>> bindtextdomain(3)
> >>>> and textdomain(3) but not uselocale(3).
> >>
> >>>> While this has resulted in a 5.28 regression / behaviour change
> >>>> for
> >>>> Perl,
> >>>> it's not clear to me whether glibc is working correctly here or
> >>>> not. Is
> >>>> this something that Perl should or could work around somehow?
> >>>
> >>> This looks like an oversight in glibc to me, hence their bug.  No
> >>> matter
> >>> how the locale gets changed, the cache should be invalidated.
> >>
> >> Thanks. I suppose I need to look at reporting this there next.
> >>> In looking at the links you provided, I didn't see how to read the
> >>> proposed patch.
> >>
> >> It just adds extra calls to bindtextdomain() and textdomain() to
> >> the application as a workaround.
> >>
> >> Hope these links work for you:
> >>
> >>
> >> https://salsa.debian.org/installer-team/console-
> >> setup/merge_requests/2/diffs
> >>
> >>
> >>
> >> https://salsa.debian.org/installer-team/console-
> >> setup/commit/0f2fc1e85a3a1d316aa28af2fe4f32e027819972
> >>
> >
> > Thanks
> >>
> >>> We should look for workarounds in case glibc refuses to change (I
> >>> don't
> >>> have respect for their willingness to acknowledge flaws in their
> >>> code),
> >>> or for working on earlier versions than any fix they do make.  I
> >>> wonder
> >>> if calling foo=textdomain(NULL);textdomain(foo);
> >>> would do it.
> >>
> >> I had a go with the attached crude patch against 5.28.1, and it does
> >> fix my test case without breaking anything in the main test suite.
> >>
> >> Obviously the textdomain() calls and the inclusion of <libintl.h>
> >> still
> >> need to be made conditional (on glibc?), so I guess a new Configure
> >> probe
> >> is needed.
> >>
> >> Are there thread safety concerns here? Do we need to worry about one
> >> thread changing the default textdomain right in the middle of
> >> another
> >> thread changing locales?
> >>
> >
> > I don't know.  The man pages mention nothing about threads.  That
> > could
> > mean an issue, or it could mean its and non-issue.  My guess is that
> > the
> > textdomain is global to all threads.  If the actual change is atomic,
> > then it would just mean that any time a thread did a uselocale, that
> > it
> > would get invalidated, and so this could happen lots.  If it isn't
> > atomic, I would expect segfaults.
> >
> > Maybe someone in glibc land would know, or someone could look at the
> > source.
> >
> 
> And we do have a locale semaphore to solve races with these.

Ticket against glibc filed: https://sourceware.org/bugzilla/show_bug.cgi?id=24936
-- 
Karl Williamson

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=134264

• [perl #134264] switching locales no longer invalidates gettexttranslation cache since 5.28 by Karl Williamson via RT