This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC]setlocale() race condition


On Wed, Jun 18, 2008 at 5:45 AM, Sharyathi Nagesh <sharyath@in.ibm.com> wrote:
> So does it look better ?

Yes and no.

>    This problem was noticed with glibc shipped with distro, with older
> version of glibc 2.5-12, the problem is noticed after 8 hours of testing and
> application crashed with SIGSEGV. My efforts to replicate the problem with
> main line glibc was not successful, but I still feel the problem is there
> even with main line glibc and wish to know your thoughts on this issue
> -----------------------------------------------------------------
> Explanation:
>    This problem was noticed during PHP engine development, current
> implementation calls setlocale() every time a page is requested. The problem
> is noticed during stress test of this PHP engine
>    setlocale() is being called on multiple threads. The exact API calls are
> as follows
> ....
> setlocale(LC_ALL,'C');
> ....
> setlocale(LC_TYPE,'');
> ....
> setlocale(LC_CTYPE,'C');
> ....
>    It was observed that after ~8 hours of testing, application crashed at
> strcmp() call made from setlocale(), when I analyzed the dump it showed that
> _nl_global_locale.__names[category] pointer was corrupted.
>    Code analysis  showed a window for race - when one thread calls
> strcmp()(with in setlocale()) with current value of
> _nl_global_locale.__names[category] passed as argument and another thread
> goes ahead and frees the string pointer pointed by
> _nl_global_locale.__names[category].
>
> _nl_global_locale.__names[category] is protected through the lock
> libc_setlocale_lock, but the lock is taken only while writing to the data
> and not while reading from the global variable;
>  This lock is taken in freelocale() and setlocale() functions

Simplify your explanation, and if you don't have a testcase then
include an analysis of the cvs head code.

e.g.
~~~
During PHP engine development it was observed that a thread calling
strcmp() would crash if a thread was also calling setlocale().
The problem is difficult to reproduce, but the following is a
line-by-line analysis of where the race condition exists.
... Point out line-by-line race condition in cvs head code ...
~~~

>  Though setlocale() is not on the POSIX.1 list of async-signal safe
> functions as in section 2.4.3
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04
> It still needs to be thread safe according to section 2.9.1 in
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html

OK.

> -----------------------------------------------------------------
> Testing:
>     Didn't notice any regression with testing. Testing was done under x86-64
> box where the application was built as 32bit.
> -----------------------------------------------------------------

What do you mean by "didn't notice?" either there was or was not a regression.

The target x86-64 is not a gnu-triplet, please use the canonical
triplet name e.g. x86_64-linux-gnu?

> Fix:
>    Similar fix, fixed the problem with distro glibc, where
> __libc_lock_lock() is used instead of __libc_rwlock_rdlock()

We don't care about your distro glibc. We care about how your patch
fixes the race condition.

Please provide a ChangeLog entry, and the patch. Lastly, you should
mention the status of your FSF copyright assignment.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]