[jira] [Issue Comment Edited] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[
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
[jira] [Issue Comment Edited] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[
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:
[jira] [Issue Comment Edited] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201653#comment-13201653
]
Stefan Teleman edited comment on STDCXX-1056 at 2/6/12 10:04 PM:
-
I understand the need for writing small and efficient methods, but I don't
agree that the problem reported in STDCXX-839 relates to the test running for
too long. The fact that the test program doesn't terminate or abends with
SIGHUP is a symptom of undefined run-time behavior.
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:49:50][1512]>> /usr/bin/time -p ./22.locale.numpunct.mt --nthreads=4
--nloops=100 >& t.out
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:50:13][1513]>> tail -17 t.out
# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO | 11 | 11 | 0% |
# | (S2) NOTE |1 |1 | 0% |
# | (S8) ERROR|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
real 4.95
user 1.07
sys 0.22
{noformat}
This test case (and the corresponding 22.locale.moneypunct.mt) consistently
exhibit run-time crashes or insane behavior (CPU being pinned at 99% forever)
without the serialization fix.
The interesting part is where this race condition actually happens: it's in
include/loc/_num_put.cc:
{code:title=_num_put.cc|borderStyle=solid}
template */>
_TYPENAME num_put<_CharT, _OutputIter>::iter_type
num_put<_CharT, _OutputIter>::
_C_put (iter_type __it, ios_base &__flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunct &__np =
_RWSTD_USE_FACET (numpunct, __flags.getloc ());
char __buf [_RWSTD_DBL_MAX_10_EXP];
// will grow as necessary and may need to be deleted
char *__pbuf = __buf;
const string__grouping = __np.grouping (); // <- !!
const char* const __grp = __grouping.c_str (); // <- !!
const _RWSTD_STREAMSIZE __prec = __flags.precision ();
{code}
was (Author: steleman):
I understand the need for writing small and efficient methods, but I don't
agree that the problem reported in STDCXX-839 relates to the test running for
too long. The fact that the test program doesn't terminate or abends with
SIGHUP is a symptom of undefined run-time behavior.
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:49:50][1512]>> /usr/bin/time -p ./22.locale.numpunct.mt --nthreads=4
--nloops=100 >& t.out
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:50:13][1513]>> tail -17 t.out
# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO | 11 | 11 | 0% |
# | (S2) NOTE |1 |1 | 0% |
# | (S8) ERROR|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
real 4.95
user 1.07
sys 0.22
{noformat}
This test case (and the corresponding 22.locale.moneypunct.mt) consistently
exhibit run-time crashes or insane behavior (CPU being pinned at 99% forever)
without the serialization fix.
The interesting part is where this race condition actually happens: it's in
include/loc/_num_put.cc:
{code title=_num_put.cc|borderStyle=solid}
template */>
_TYPENAME num_put<_CharT, _OutputIter>::iter_type
num_put<_CharT, _OutputIter>::
_C_put (iter_type __it, ios_base &__flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunct &__np =
_RWSTD_USE_FACET (numpunct, __flags.getloc ());
char __buf [_RWSTD_DBL_MAX_10_EXP];
// will grow as necessary and may need to be deleted
char *__pbuf = __buf;
const string__grouping = __np.grouping (); // <- !!
const char* const __grp = __grouping.c_str (); // <- !!
const _RWSTD_STREAMSIZE __prec = __flags.precision ();
{code}
> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
>
[jira] [Issue Comment Edited] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
[
https://issues.apache.org/jira/browse/STDCXX-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201653#comment-13201653
]
Stefan Teleman edited comment on STDCXX-1056 at 2/6/12 10:02 PM:
-
I understand the need for writing small and efficient methods, but I don't
agree that the problem reported in STDCXX-839 relates to the test running for
too long. The fact that the test program doesn't terminate or abends with
SIGHUP is a symptom of undefined run-time behavior.
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:49:50][1512]>> /usr/bin/time -p ./22.locale.numpunct.mt --nthreads=4
--nloops=100 >& t.out
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:50:13][1513]>> tail -17 t.out
# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO | 11 | 11 | 0% |
# | (S2) NOTE |1 |1 | 0% |
# | (S8) ERROR|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
real 4.95
user 1.07
sys 0.22
{noformat}
This test case (and the corresponding 22.locale.moneypunct.mt) consistently
exhibit run-time crashes or insane behavior (CPU being pinned at 99% forever)
without the serialization fix.
The interesting part is where this race condition actually happens: it's in
include/loc/_num_put.cc:
{code title=_num_put.cc|borderStyle=solid}
template */>
_TYPENAME num_put<_CharT, _OutputIter>::iter_type
num_put<_CharT, _OutputIter>::
_C_put (iter_type __it, ios_base &__flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunct &__np =
_RWSTD_USE_FACET (numpunct, __flags.getloc ());
char __buf [_RWSTD_DBL_MAX_10_EXP];
// will grow as necessary and may need to be deleted
char *__pbuf = __buf;
const string__grouping = __np.grouping (); // <- !!
const char* const __grp = __grouping.c_str (); // <- !!
const _RWSTD_STREAMSIZE __prec = __flags.precision ();
{code}
was (Author: steleman):
I understand the need for writing small and efficient methods, but I don't
agree that the problem reported in STDCXX-839 relates to the test running for
too long. The fact that the test program doesn't terminate or abends with
SIGHUP is a symptom of undefined run-time behavior.
{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:49:50][1512]>> /usr/bin/time -p ./22.locale.numpunct.mt --nthreads=4
--nloops=100 >& t.out
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/stdcxx-4.2.1/build/tests][02/06/2012
16:50:13][1513]>> tail -17 t.out
# INFO (S1) (4 lines):
# TEXT: creating a thread pool with 4 threads
# CLAUSE: lib.locale.numpunct
# LINE: 548
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO | 11 | 11 | 0% |
# | (S2) NOTE |1 |1 | 0% |
# | (S8) ERROR|0 |3 | 100% |
# | (S9) FATAL|0 |1 | 100% |
# +---+--+--+--+
real 4.95
user 1.07
sys 0.22
{noformat}
This test case (and the corresponding 22.locale.moneypunct.mt) consistently
exhibit run-time crashes or insane behavior (CPU being pinned at 99% forever)
without the serialization fix.
The interesting part is where this race condition actually happens: it's in
include/loc/_num_put.cc:
{code title=_num_put.cc|borderStyle=solid}
template */>
_TYPENAME num_put<_CharT, _OutputIter>::iter_type
num_put<_CharT, _OutputIter>::
_C_put (iter_type __it, ios_base &__flags, char_type __fill, int __type,
const void *__pval) const
{
const numpunct &__np =
_RWSTD_USE_FACET (numpunct, __flags.getloc ());
char __buf [_RWSTD_DBL_MAX_10_EXP];
// will grow as necessary and may need to be deleted
char *__pbuf = __buf;
const string__grouping = __np.grouping (); // <- !!
const char* const __grp = __grouping.c_str (); // <- !!
const _RWSTD_STREAMSIZE __prec = __flags.precision ();
// [ ... ]
{code}
> std::moneypunct and std::numpunct implementations are not thread-safe
> -
>
>
