Bug 1001643

Summary: harfbuzz: unexpected use of thread-unsafe setlocale function
Product: Red Hat Enterprise Linux 7 Reporter: Florian Weimer <fweimer>
Component: harfbuzzAssignee: Parag Nemade <pnemade>
Status: CLOSED NOTABUG QA Contact: QE Internationalization Bugs <qe-i18n-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: behdad
Target Milestone: rcKeywords: i18n
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-09 15:55:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1001533    

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?