Bug 1001643 - harfbuzz: unexpected use of thread-unsafe setlocale function
Summary: harfbuzz: unexpected use of thread-unsafe setlocale function
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: harfbuzz
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Parag Nemade
QA Contact: QE Internationalization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1001533
TreeView+ depends on / blocked
 
Reported: 2013-08-27 12:55 UTC by Florian Weimer
Modified: 2013-10-09 15:55 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-09 15:55:32 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Florian Weimer 2013-08-27 12:55:31 UTC
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 14:46:07 UTC
I don't know of any thread-safe alternatives to setlocale().

Comment 3 Florian Weimer 2013-08-27 15:02:37 UTC
(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 15:15:57 UTC
(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 15:16:24 UTC
Basically what we are relying on is that user doesn't change locale after spawning multiple threads.

Comment 6 Parag Nemade 2013-09-10 06:20:18 UTC
Florian,
   Can this be closed as NOTABUG?


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