[Bug locale/23970] [Bug] Fix race condition between uselocale/setlocale and duplocale

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

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

--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Akhilesh from comment #3)
> Yes we Agree that setlocale() is not MT-safe. But we are getting the same
> issue  even with LC_GLOBAL_LOCALE. 

(In reply to Akhilesh from comment #4)
> Even with out freelocale also we are getting "memory corruption"

The example you are showing is *still* using setlocale() and it is not MT-safe.
All locale using functions in threads may crash, corrupt data, or worse if you
call setlocale() without coordination from all threads.

The glibc manual and C11 call out that setlocale() is not thread safe.

> Also I Think we should not restrict application developer, Also in any
> scenario glibc should not corrupts its metadata. Since proposed fix,
> Protects the heap corruption to avoid undefined behavior, we can consider
> this. 

(1) Restricting the application developer.

Some restrictions have to exist for performance reasons.

To make setlocale() MT-safe would require locking all locale using functions to
avoid setlocale() causing data races, and the runtime cost for that is very
high, therefore we leave it MT-unsafe.

You *can* use setlocale() to change locales, but the *developer* must handle
the coordination between all threads.

(2) glibc should not corrupt its metadata.

See "10.2. Bugs in the user program"
https://sourceware.org/glibc/wiki/Style_and_Conventions#Error_Handling

We give preference to correctly running well defined programs, and generally we
do not extend the size of the critical section (what your patch does) to try
make undefined behaviour work properly. It adds latency (larger critical
section) for no reward.

> Also we found same protection in newlocale but not in duplocale.

(3) newlocale has locking.

In both newlocale and duplocale we have locking because both functions are
designed to be MT-safe with respect to: uselocale, newlocale, duplocale,
freelocale. All 4 functions are designed to be used from threads, and must be
MT-safe (so long as the passed in locale is not free'd via freelocale by
another thread, that's a user-created data race and undefined behaviour).

You have not provided any strong rationale for making setlocale() MT-safe, and
worse making it MT-safe has significant performance cost for little benefit.

Does that explain my position?

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