Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#292 closed defect (fixed)

setlocale may not be SMP safe

Reported by: Steven Levine Owned by:
Priority: normal Milestone: libc-0.6.6
Component: libc Version: 0.6.5
Severity: normal Keywords: smp


This issue was encountered for

which includes exceptq .trp files that imply that the locale impelementation may not be SMP safe. Locale updates are SMP safe because they are serialized. However, accesses to global locale data such as is done at:


zdot[1] = __libc_gLocaleLconv.s.decimal_point[0];

are not serialized. It seems that there is a small window in localeCommit between the time localeNumericFree() is invoked and __libc_gLocaleLconv.s.decimal_point is set where the pointer is NULL and an access by some other CPU will result in an exception.

Change History (3)

comment:1 Changed 6 years ago by Steven Levine

Milestone: libc-0.7libc-0.6.6

comment:2 Changed 6 years ago by bird

Resolution: fixed
Status: newclosed

I don't think setlocale is guaranteed to global thread-safety while updating the global locale data. (See for instance.)

Currently lacking good read-write locks, I cannot do much better than making sure the pointer is never NULL and to avoid replacing strings with the same value (as I kind of suspect this could actually turn out to be). The race between someone reading the pointer and setlocale calling free on it is still present. Changes committed in r3915 (branch) and r3916 (trunk).

Marking this as fixed as the real fix here is implementing the newer locale APIs.

comment:3 Changed 6 years ago by bird

r3936 fixes a bug in the default & C/POSIX monetary locale uncovered by these changes.

Note: See TracTickets for help on using tickets.