stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Teleman (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
Date Wed, 08 Feb 2012 00:27:04 GMT

    [ 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/8/12 12:25 AM:
-----------------------------------------------------------------

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_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 -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.

                  
> 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

        

Mime
View raw message