[jira] [Commented] (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=13200663#comment-13200663 ] Stefan Teleman commented on STDCXX-1056: Test cases for this defect are: 22.locale.moneypunct.mt and 22.locale.numpunct.mt. See also STDCXX-839: https://issues.apache.org/jira/browse/STDCXX-839 > 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 > > > 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
[jira] [Updated] (STDCXX-1058) std::basic_ios<>::copyfmt() with registered callback (via std::ios_base::register_callback()) run-time SIGABRT
[
https://issues.apache.org/jira/browse/STDCXX-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Teleman updated STDCXX-1058:
---
Attachment: test.cc
Jira reformats code. Sigh.
> std::basic_ios<>::copyfmt() with registered callback (via
> std::ios_base::register_callback()) run-time SIGABRT
> ---
>
> Key: STDCXX-1058
> URL: https://issues.apache.org/jira/browse/STDCXX-1058
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
> Environment: Solaris 10 and 11, Red Hat Linux, OpenSuSE Linux
> Sun C++ Compilers 12.1, 12.2, 12.3
> Defect is independent of platform or compiler.
>Reporter: Stefan Teleman
> Labels: crash, segmenation_fault
> Fix For: 4.2.x, 4.3.x, 5.0.0
>
> Attachments: test.cc
>
>
> A stream with a registered callback via register_callback() SIGABRTs at
> run-time:
> #include
> #include
> int x;
> void testfun (std::ios_base::event ev, std::ios_base& iosobj, int index)
> {
> x = index;
> switch (ev)
> {
> case std::ios_base::copyfmt_event:
> std::cerr << "copyfmt_event" << std::endl; break;
> case std::ios_base::imbue_event:
> std::cerr << "imbue_event" << std::endl; break;
> case std::ios_base::erase_event:
> std::cerr << "erase_event" << std::endl; break;
> default:
> std::cerr << "unknown" << std::endl; break;
> }
> }
> int main ()
> {
> std::fstream f0;
> std::fstream f1;
> int i = 101;
> std::ios_base::event_callback e1 = &testfun;
> f0.register_callback (e1, i);
> x = 0;
> f0.imbue (std::cerr.getloc());
> if (x != i)
> std::cerr << "x: expected " << i << " got " << x << std::endl;
> x = 0;
> f0.copyfmt (f1);
> if (x != i)
> std::cerr << "x: expected " << i << " got " << x << std::endl;
> return 0;
> }
> Output from GCC 4.5.0:
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
> 0:32:42][1340]>> ./test-gcc
> imbue_event
> erase_event
> Output from Sun C++ 12.2 with stlport4:
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
> 0:32:44][1341]>> ./test-ss12-stlport
> imbue_event
> erase_event
> copyfmt_event
> erase_event
> Output from Sun C++ 12.2 with our stdcxx (patched):
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
> 0:32:58][1342]>> ./test-ss12-stdcxx
> imbue_event
> erase_event
> Output from Pathscale 4.0.12.1 (which didn't patch stdcxx):
> [steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
> 0:33:03][1343]>> ./test-pathscale
> imbue_event
> erase_event
> *** glibc detected *** ./test-pathscale: double free or corruption (fasttop):
> 0x 0605480 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x73286)[0x7f78cbb7f286]
> /lib64/libc.so.6(cfree+0x6c)[0x7f78cbb8402c]
> /opt/pathscale/ekopath-4.0.12.1/lib/4.0.12.1/x8664/64/libcxxrt.so(_ZdlPv+0xd)[0x
> f78cc097d63]
> /opt/pathscale/ekopath-4.0.12.1/lib/4.0.12.1/x8664/64/libstl.so(_ZNSt8ios_base11
> C_usr_data10_C_deallocEPS0_+0x2d)[0x7f78cc300b5b]
> === Memory map:
> 0040-00404000 r-xp 103:00 9582413
> /src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt/test-pathscale
> 00603000-00604000 r--p 3000 103:00 9582413
> /src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt/test-pathscale
> 00604000-00605000 rw-p 4000 103:00 9582413
> /src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt/test-pathscale
> 00605000-00626000 rw-p 00:00 0
> [heap]
> [ ... ]
> I no longer have an unpatched stdcxx handy for the Sun C++ compilers available
> to reproduce the defect with the Sun C++ compiler.
> Defect is in file src/iostore.cpp, starting at line 275:
> _C_usr->_C_iarray, _C_usr->_C_parray and _C_usr->_C_cbarray
> are not set to NULL after deletion:
> _TRY {
> if (_C_usr) {
> // fire erase events (27.4.4.2, p17) - may throw
> if (_C_usr->_C_fire)
> (this->*_C_usr->_C_fire)(erase_event, true /* reentrant */);
> // delete existing arrays, if any; _C_usr will only be deleted
> // if `rhs' contains no user data (see below)
> operator delete (_C_usr->_C_iarray);
> _C_usr->_C_iarray = 0UL; // <- !!
> operator delete (_C_usr->_C_parray);
> _C_usr->_C_parray = 0UL; // <- !!
> operator delete (_C_usr->_C_cbarray);
[jira] [Created] (STDCXX-1058) std::basic_ios<>::copyfmt() with registered callback (via std::ios_base::register_callback()) run-time SIGABRT
std::basic_ios<>::copyfmt() with registered callback (via
std::ios_base::register_callback()) run-time SIGABRT
---
Key: STDCXX-1058
URL: https://issues.apache.org/jira/browse/STDCXX-1058
Project: C++ Standard Library
Issue Type: Bug
Components: 27. Input/Output
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
Environment: Solaris 10 and 11, Red Hat Linux, OpenSuSE Linux
Sun C++ Compilers 12.1, 12.2, 12.3
Defect is independent of platform or compiler.
Reporter: Stefan Teleman
Fix For: 4.2.x, 4.3.x, 5.0.0
A stream with a registered callback via register_callback() SIGABRTs at
run-time:
#include
#include
int x;
void testfun (std::ios_base::event ev, std::ios_base& iosobj, int index)
{
x = index;
switch (ev)
{
case std::ios_base::copyfmt_event:
std::cerr << "copyfmt_event" << std::endl; break;
case std::ios_base::imbue_event:
std::cerr << "imbue_event" << std::endl; break;
case std::ios_base::erase_event:
std::cerr << "erase_event" << std::endl; break;
default:
std::cerr << "unknown" << std::endl; break;
}
}
int main ()
{
std::fstream f0;
std::fstream f1;
int i = 101;
std::ios_base::event_callback e1 = &testfun;
f0.register_callback (e1, i);
x = 0;
f0.imbue (std::cerr.getloc());
if (x != i)
std::cerr << "x: expected " << i << " got " << x << std::endl;
x = 0;
f0.copyfmt (f1);
if (x != i)
std::cerr << "x: expected " << i << " got " << x << std::endl;
return 0;
}
Output from GCC 4.5.0:
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
0:32:42][1340]>> ./test-gcc
imbue_event
erase_event
Output from Sun C++ 12.2 with stlport4:
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
0:32:44][1341]>> ./test-ss12-stlport
imbue_event
erase_event
copyfmt_event
erase_event
Output from Sun C++ 12.2 with our stdcxx (patched):
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
0:32:58][1342]>> ./test-ss12-stdcxx
imbue_event
erase_event
Output from Pathscale 4.0.12.1 (which didn't patch stdcxx):
[steleman@darthvader][/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt][02/05/2012
0:33:03][1343]>> ./test-pathscale
imbue_event
erase_event
*** glibc detected *** ./test-pathscale: double free or corruption (fasttop):
0x 0605480 ***
=== Backtrace: =
/lib64/libc.so.6(+0x73286)[0x7f78cbb7f286]
/lib64/libc.so.6(cfree+0x6c)[0x7f78cbb8402c]
/opt/pathscale/ekopath-4.0.12.1/lib/4.0.12.1/x8664/64/libcxxrt.so(_ZdlPv+0xd)[0x
f78cc097d63]
/opt/pathscale/ekopath-4.0.12.1/lib/4.0.12.1/x8664/64/libstl.so(_ZNSt8ios_base11
C_usr_data10_C_deallocEPS0_+0x2d)[0x7f78cc300b5b]
=== Memory map:
0040-00404000 r-xp 103:00 9582413
/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt/test-pathscale
00603000-00604000 r--p 3000 103:00 9582413
/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt/test-pathscale
00604000-00605000 rw-p 4000 103:00 9582413
/src/steleman/programming/stdcxx-ss122/bugfixes-sunw/fstream.copyfmt/test-pathscale
00605000-00626000 rw-p 00:00 0 [heap]
[ ... ]
I no longer have an unpatched stdcxx handy for the Sun C++ compilers available
to reproduce the defect with the Sun C++ compiler.
Defect is in file src/iostore.cpp, starting at line 275:
_C_usr->_C_iarray, _C_usr->_C_parray and _C_usr->_C_cbarray
are not set to NULL after deletion:
_TRY {
if (_C_usr) {
// fire erase events (27.4.4.2, p17) - may throw
if (_C_usr->_C_fire)
(this->*_C_usr->_C_fire)(erase_event, true /* reentrant */);
// delete existing arrays, if any; _C_usr will only be deleted
// if `rhs' contains no user data (see below)
operator delete (_C_usr->_C_iarray);
_C_usr->_C_iarray = 0UL; // <- !!
operator delete (_C_usr->_C_parray);
_C_usr->_C_parray = 0UL; // <- !!
operator delete (_C_usr->_C_cbarray);
_C_usr->_C_cbarray = 0UL; // <- !!
}
Patch for 4.2.1 to follow shortly.
--
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
[jira] [Commented] (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=13200645#comment-13200645 ] Martin Sebor commented on STDCXX-1056: -- What you describe sounds like a bug in the implementation of std::string (it could also be a bug in the thread safety of the facets) which is supposed to be thread safe. We have pretty thorough tests for the thread safety of the string classes but it's certainly possible that there's a bug. I suspect the thread safety tests for facets are much weaker. FYI: the plan for stdcxx 5.0 has been to change the default configuration of basic_string to not be reference counted for efficiency on SMP systems. We can't make this change in 4.x because of binary compatibility, although I think there's a macro that lets you control it if you don't care about binary compatibility. If there's a bug in the thread safety of the facet classes (which is quite possible, especially with their lazy initialization), we should be able to fix it without breaking compatibility. > 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 > > > 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
[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification
[ https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200643#comment-13200643 ] Martin Sebor commented on STDCXX-1055: -- (2) is an extension (it may even be a documented somewhere). We can add a macro to disable the extension, but the 4.2.x default needs to stay the same for both source and binary compatibility (IIRC, Visual C++ mangles access into the name of the function). I'm interested to see how (1) and (3) are detectable by a conforming program (we'll need a test case to exercise this). > some of the localization class declarations do not follow the > ISO/IEC:14882:2003 specification > -- > > Key: STDCXX-1055 > URL: https://issues.apache.org/jira/browse/STDCXX-1055 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0 > Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ > Compiler 12.1, 12.2, 12.3, GCC4. > The defect is independent of platform or compiler. >Reporter: Stefan Teleman > Labels: conformance, standards > Fix For: 4.2.x, 4.3.x, 5.0.0 > > > For the following classes: > std::codecvt<> and its specializations > std::collate<> and its specializations > std::ctype<> and its specializations > std::ctype_byname<> and its specializations > std::messages<> and its specializations > std::messages_byname<> and its specializations > std::money_get<> and its specializations > std::moneypunct<> and is specializations > std::moneypunct_byname<> and its specializations > std::money_put<> and its specializations > std::num_get<> and its specializations > std::numpunct<> and its specializations > std::numpunct_byname<> and its specializations > std::num_put<> and its specializations > std::time_get<> and its specializations > std::time_get_byname<> and its specializations > std::time_put<> and its specializations > 1. all these type declarations must be of class type (and not of struct type) > 2. all these classes must have protected virtual destructors > 3. all the corresponding *_base (time_base, money_base, etc), must have > virtual destructors > The current implementation of these types as structs (with default public > access > specifier on their non-virtual destructors) causes failures in Perennial > CPPVS V8.1. > Changing the access specifier for these destructors requires some changes in > the > stdcxx tests for localization. > Patch based on 4.2.1 to follow shortly. -- 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
[jira] [Created] (STDCXX-1057) attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1
attempting to create a std::string of size 65535 or greater fails with Perennial CPPVS V8.1 --- Key: STDCXX-1057 URL: https://issues.apache.org/jira/browse/STDCXX-1057 Project: C++ Standard Library Issue Type: Bug Components: 21. Strings Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 Environment: Solaris 10 and 11, RedHat Linux, OpenSuSE Linux SUN C++ Compilers 12.1, 12.2, 12.3 Defect is independent of compiler and platform Reporter: Stefan Teleman Fix For: 4.2.x, 4.3.x, 5.0.0 in member function: size_type basic_string<_CharT, _Traits, _Allocator>::max_size(); the maximum size of a basic_string is restricted to less than 65535 bytes. The Standard is ambiguous as to what the max_size() of a std::string should actually be (see LWG Core Issue 197). However, less than 65535 bytes for the max_size of a std::string is rather small. GNU libstdc++ and stlport4 set std::string::max_size to (SIZE_MAX / 4) (i.e. 1GB). Solaris sets it to SIZE_MAX. Perennial CPPVS explicitly tests for the creation of a std::string of size greater than 65535. In the current stdcxx implementation, this test fails. The max_size of a std::string should be significantly greater than 65535 bytes. Patch for 4.2.1 to follow shortly. -- 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
[jira] [Created] (STDCXX-1056) std::moneypunct and std::numpunct implementations are not thread-safe
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 Fix For: 4.2.x, 4.3.x, 5.0.0 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
[jira] [Created] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification
some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification -- Key: STDCXX-1055 URL: https://issues.apache.org/jira/browse/STDCXX-1055 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ Compiler 12.1, 12.2, 12.3, GCC4. The defect is independent of platform or compiler. Reporter: Stefan Teleman Fix For: 4.2.x, 4.3.x, 5.0.0 For the following classes: std::codecvt<> and its specializations std::collate<> and its specializations std::ctype<> and its specializations std::ctype_byname<> and its specializations std::messages<> and its specializations std::messages_byname<> and its specializations std::money_get<> and its specializations std::moneypunct<> and is specializations std::moneypunct_byname<> and its specializations std::money_put<> and its specializations std::num_get<> and its specializations std::numpunct<> and its specializations std::numpunct_byname<> and its specializations std::num_put<> and its specializations std::time_get<> and its specializations std::time_get_byname<> and its specializations std::time_put<> and its specializations 1. all these type declarations must be of class type (and not of struct type) 2. all these classes must have protected virtual destructors 3. all the corresponding *_base (time_base, money_base, etc), must have virtual destructors The current implementation of these types as structs (with default public access specifier on their non-virtual destructors) causes failures in Perennial CPPVS V8.1. Changing the access specifier for these destructors requires some changes in the stdcxx tests for localization. Patch based on 4.2.1 to follow shortly. -- 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
