[ https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202730#comment-13202730 ]
Stefan Teleman commented on STDCXX-1056: ---------------------------------------- I had to resurrect all my linux patches, and because I hadn't worked on the Linux stdcxx for a while I had forgotten a bunch of things: 1. makefile.in: {noformat} TOPDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe BUILDDIR = /src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/build CONFIG = $(TOPDIR)/etc/config/gcc.config CONFIG_H = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti -fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT BUILDTYPE = 8d BUILDMODE = shared,pthreads CXX = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti -fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -D_RWSTD_NO_EXT_OPERATOR_NEW -D_RWSTD_NO_OPERATOR_NEW_ARRAY -D_RWSTD_NO_REPLACEABLE_NEW_DELETE CXXFLAGS = -pedantic -nostdinc++ PRELINKFLAGS = PICFLAGS = -fPIC CPPFLAGS = -I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/ansi -I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include/tr1 -I/src/steleman/programming/stdcxx-gcc/stdcxx-4.2.1-thread-safe/include -nostdinc++ -pthread WARNFLAGS = -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align DEPENDFLAGS = -M DEPENDFLAGS.cpp = DEPENDFLAGS.S = AS_EXT = .S LD = /usr/bin/g++ -m32 -g -O2 -fno-strict-aliasing -frtti -fkeep-inline-functions -D_REENTRANT -D_RWSTD_REENTRANT -nodefaultlibs --allow-shlib-undefined LDFLAGS = -lc -lm -lpthread LDLIBS = /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libgcc_eh.a /usr/lib64/gcc/x86_64-suse-linux/4.5/32/libsupc++.a LDSOFLAGS = -shared MAPFLAGS = RPATH = -Wl,-R RUNFLAGS = -t 300 DEPENDDIR = .depend PHDIR = PHWARNFLAGS = LIBSUFFIX = .so LIBBASE = std$(BUILDTYPE) LIBVER = 4.2.1 LIBNAME = lib$(LIBBASE)$(LIBSUFFIX) AR = ar ARFLAGS = rv CCVER = 4.5 SHARED = CATFILE = OMIT_EXM_SRCS = OMIT_TST_SRCS = BUILDTAG = PLATFORM = linux-2.6.34.10-0.4-desktop-x86_64 DEFAULT_SHROBJ = WITH_CADVISE = CADVISEFLAGS = WITH_PURIFY = PURIFYFLAGS = CXX_REPOSITORY = {noformat} Make sure libstd8d.so.4.2.1 does *NOT* link with libstdc++.so. It needs to statically link with libsupc++.a and libgcc_eh.a. > std::moneypunct and std::numpunct implementations are not thread-safe > --------------------------------------------------------------------- > > Key: STDCXX-1056 > URL: https://issues.apache.org/jira/browse/STDCXX-1056 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization > Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 > Environment: Solaris 10 and 11, RedHat and OpenSuSE Linux, Sun C++ > Compilers 12.1, 12.2, 12.3 > Issue is independent of platform and/or compiler. > Reporter: Stefan Teleman > Labels: thread-safety > Fix For: 4.2.x, 4.3.x, 5.0.0 > > Attachments: 22.locale.numpunct.mt.out, stdcxx-1056.patch > > > several member functions in std::moneypunct<> and std::numpunct<> return > a std::string by value (as required by the Standard). The implication of > return-by-value > being that the caller "owns" the returned object. > In the stdcxx implementation, the std::basic_string copy constructor uses a > shared > underlying buffer implementation. This shared buffer creates the first > problem for > these classes: although the std::string object returned by value *appears* to > be owned > by the caller, it is, in fact, not. > In a mult-threaded environment, this underlying shared buffer can be > subsequently modified by a different thread than the one who made the initial > call. Furthermore, two or more different threads can access the same shared > buffer at the same time, and modify it, resulting in undefined run-time > behavior. > The cure for this defect has two parts: > 1. the member functions in question must truly return a copy by avoiding a > call to the copy constructor, and using a constructor which creates a deep > copy of the std::string. > 2. access to these member functions must be serialized, in order to guarantee > atomicity > of the creation of the std::string being returned by value. > Patch for 4.2.1 to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira