Bug 1001643 - harfbuzz: unexpected use of thread-unsafe setlocale function
harfbuzz: unexpected use of thread-unsafe setlocale function
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: harfbuzz (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Parag Nemade
QE Internationalization Bugs
: i18n
Depends On:
Blocks: 1001533
  Show dependency treegraph
 
Reported: 2013-08-27 08:55 EDT by Florian Weimer
Modified: 2013-10-09 11:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-09 11:55:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Florian Weimer 2013-08-27 08:55:31 EDT
src/hb-common.cc:hb_language_get_default() uses setlocale(), which is not thread-safe, in a context which is clearly intended as thread-safe due to the presence of atomics.  The function should use a thread-safe way to obtain the necessary information instead.
Comment 2 Behdad Esfahbod 2013-08-27 10:46:07 EDT
I don't know of any thread-safe alternatives to setlocale().
Comment 3 Florian Weimer 2013-08-27 11:02:37 EDT
(In reply to Behdad Esfahbod from comment #2)
> I don't know of any thread-safe alternatives to setlocale().

I'm not sure what Harfbuzz is doing with the returned string.  In principle, there are newlocale(), uselocale() and nl_langinfo_l() which could be used to emulate this functionality without changing global state.
Comment 4 Behdad Esfahbod 2013-08-27 11:15:57 EDT
(In reply to Florian Weimer from comment #3)
> (In reply to Behdad Esfahbod from comment #2)
> > I don't know of any thread-safe alternatives to setlocale().
> 
> I'm not sure what Harfbuzz is doing with the returned string.

We copy it and never use it again.

>  In principle,
> there are newlocale(), uselocale() and nl_langinfo_l() which could be used
> to emulate this functionality without changing global state.

All we are doing is to query the current set locale.  We don't change the global state.  I don't see any way to query current locale with any other function.  The alternative would be to query the envvars, which means user's setlocale() will be ignored.
Comment 5 Behdad Esfahbod 2013-08-27 11:16:24 EDT
Basically what we are relying on is that user doesn't change locale after spawning multiple threads.
Comment 6 Parag Nemade 2013-09-10 02:20:18 EDT
Florian,
   Can this be closed as NOTABUG?

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