[Bug libc/24936] gettext cache not invalidated by uselocale()

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=24936

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2019-08-28
                 CC|                            |carlos at redhat dot com
     Ever confirmed|0                           |1

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
I can confirm running the program and seeing:

[carlos@athas swbz24936]$ ./test
lauseoppivirhe
lauseoppivirhe
lauseoppivirhe

[carlos@athas swbz24936]$ ./test fix
lauseoppivirhe
erreur de syntaxe
syntax error

It does seem like a defect that we don't increment _nl_msg_cat_cntr when
calling uselocale to set the thread-local locale.

The real problem is that _nl_msg_cat_cntr is a global variable that is
accessesed by all threads under what appears to be a mix of
__libc_setlocale_lock and _nl_state_lock, which also seems wrong and prone to
producing a counter that is incorrectly updated.

Worse is that because two locks are used to update the data structures, but
only one _nl_msg_cat_cntr, it might lead to a case where an update happened in
thread A, using __libc_setlocale_lock, and then thread B did an update, using
_nl_state_lock, it might see an old value of _nl_msg_cat_cntr, because the
locks are different, and writes in thread A are not guaranteed to be seen by
thread B. Likewise for other parts of the locales.

The solution requires a full review of the locking around _nl_msg_cat_cntr,
__libc_setlocale, and _nl_state_lock. Then uselocale needs to be updated to
indicate that the locale change invalidates the lookup cache.

Looks like a real bug to me.

-- 
You are receiving this mail because:
You are on the CC list for the bug.