[
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202730#comment-13202730
]
Stefan Teleman edited comment on STDCXX-1056 at 2/7/12 11:31 PM:
-----------------------------------------------------------------
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 -lgcc_s
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.
was (Author: steleman):
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, runtests.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
