Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#292 closed defect (fixed)

setlocale may not be SMP safe

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

Description

This issue was encountered for

http://mantis.smedley.id.au/view.php?id=611

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:

_output.c:827

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 5 years ago by stevenhl

  • Milestone changed from libc-0.7 to libc-0.6.6

comment:2 Changed 5 years ago by bird

  • Resolution set to fixed
  • Status changed from new to closed

I don't think setlocale is guaranteed to global thread-safety while updating the global locale data. (See http://www.remlab.net/op/oss-lib-threads.shtml 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 5 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.