[jira] [Commented] (STDCXX-1072) [Oracle Solaris/SPARCV8] stricter mutex alignment requirements
[
https://issues.apache.org/jira/browse/STDCXX-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465554#comment-13465554
]
Liviu Nicoara commented on STDCXX-1072:
---
The kernel patch changed the alignment of the userland mutex objects from a
machine word to a double-word boundary. No changes are required of the users
who use such objects in their programs unless users create mutex objects in
buffers which may not be aligned on a proper boundary. E.g., the following are
safe:
{noformat}
mutex_t lock;
struct S {
char misalign;
mutex_t lock;
};
{noformat}
whereas the following is not:
{noformat}
union {
void* align;
char buf [sizeof mutex_t];
} u;
new (u) mutex_t;
{noformat}
because the alignment requirements for void pointer are less strict than for
mutex_t. A few places in the library use the latter for all sorts of static
objects (mostly local statics).
[Oracle Solaris/SPARCV8] stricter mutex alignment requirements
--
Key: STDCXX-1072
URL: https://issues.apache.org/jira/browse/STDCXX-1072
Project: C++ Standard Library
Issue Type: Bug
Components: Thread Safety
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0, 4.2.1
Environment: Oracle Solaris on SPARC V8 (or V9 emulation?) hardware.
Reporter: Liviu Nicoara
Labels: SPARC, Solaris, V8, alignment, mutex
Fix For: 4.2.x, 4.3.x, 5.0.0
Original Estimate: 4h
Remaining Estimate: 4h
The issue has been reported in STDCXX-1066. The originator was apparently an
improvement (as a response to CR 6296770: http://tinyurl.com/8ohjsgl) shipped
with KU 137111-01 (http://tinyurl.com/ceet6ec) which requires stricter
alignment than the machine word for userland mutexes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (STDCXX-1072) [Oracle Solaris/SPARCV8] stricter mutex alignment requirements
[
https://issues.apache.org/jira/browse/STDCXX-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liviu Nicoara updated STDCXX-1072:
--
Attachment: patch.diff
[Oracle Solaris/SPARCV8] stricter mutex alignment requirements
--
Key: STDCXX-1072
URL: https://issues.apache.org/jira/browse/STDCXX-1072
Project: C++ Standard Library
Issue Type: Bug
Components: Thread Safety
Affects Versions: 4.1.2, 4.1.3, 4.1.4, 4.2.0, 4.2.1
Environment: Oracle Solaris on SPARC V8 (or V9 emulation?) hardware.
Reporter: Liviu Nicoara
Labels: SPARC, Solaris, V8, alignment, mutex
Fix For: 4.2.x, 4.3.x, 5.0.0
Attachments: patch.diff
Original Estimate: 4h
Remaining Estimate: 4h
The issue has been reported in STDCXX-1066. The originator was apparently an
improvement (as a response to CR 6296770: http://tinyurl.com/8ohjsgl) shipped
with KU 137111-01 (http://tinyurl.com/ceet6ec) which requires stricter
alignment than the machine word for userland mutexes.
Quoting here the Fujitsu patch notes (in case it goes away):
{quote}
{noformat}
2) When an application using the mutex lock or rw lock in the way shown below
is executed. (*1, *2) ...
*2) ... example of programming that causes the ... problem.
In the case where the problem occurs
int *ip;
mutex_t *mp;
ip = (int *) malloc(sizeof (int) + sizeof (mutex_t));
mp = (mutex_t *) (ip + 1);
/* The address is used with a modification */
In the case where the problem does not occur -1
mutex_t mp; /* Obtained statically */
In the case where the problem does not occur -2
mutex_t *mp;
mp = (mutex_t *) malloc(sizeof (mutex_t));
/* The address is used without any modifications */
{noformat}
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (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:all-tabpanel ] Liviu Nicoara closed STDCXX-1056. - Resolution: Duplicate Closing and continuing work on STDCXX-1071. 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 Assignee: Liviu Nicoara Labels: thread-safety Fix For: 4.2.x, 4.3.x, 5.0.0 Attachments: 22.locale.numpunct.mt.out, facet.cpp.diff, locale_body.cpp.diff, punct.cpp.diff, runtests-linux32-all.out, runtests-linux64-all.out, runtests.out, STDCXX-1056-additional-timings.tgz, stdcxx-1056.patch, stdcxx-1056-timings.tgz, stdcxx-4.2.x-numpunct-perfect-forwarding.patch, stdcxx-4.3.x-numpunct-perfect-forwarding.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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (STDCXX-1066) SPARCV8 requires pthread_mutex_t and pthread_cond_t to be aligned on an 8-byte boundary
[ https://issues.apache.org/jira/browse/STDCXX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Nicoara updated STDCXX-1066: -- Environment: Solaris 10 Update 6 or later on SPARCV8 \[32-bit\] Defect is compiler-independent - in reality it only affects Sun Studio and GCC. was: Solaris 10 Update 6 or later on SPARCV8 [32-bit] Defect is compiler-independent - in reality it only affects Sun Studio and GCC. SPARCV8 requires pthread_mutex_t and pthread_cond_t to be aligned on an 8-byte boundary --- Key: STDCXX-1066 URL: https://issues.apache.org/jira/browse/STDCXX-1066 Project: C++ Standard Library Issue Type: Bug Components: Thread Safety Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x Environment: Solaris 10 Update 6 or later on SPARCV8 \[32-bit\] Defect is compiler-independent - in reality it only affects Sun Studio and GCC. Reporter: Stefan Teleman Labels: features, runtime, threads Fix For: 4.2.2, 4.2.x, 4.3.x Attachments: _config-gcc.h.stdcxx-1066.patch, _config-sunpro.h.stdcxx-1066.patch, ctype.cpp.stdcxx-1066.patch, exception.cpp.stdcxx-1066.patch, ios.cpp.stdcxx-1066.patch, iostream.cpp.stdcxx-1066.patch, iostream.stdcxx-1066.patch, locale_body.cpp.stdcxx-1066.patch, locale_classic.cpp.stdcxx-1066.patch, messages.cpp.stdcxx-1066.patch, _mutex.h.stdcxx-1066.patch, time_put.cpp.stdcxx-1066.patch, use_facet.h.stdcxx-1066.patch Starting with Solaris 10 Update 6, on SPARCV8, pthread_mutex_t and pthread_cond_t MUST be aligned on an 8-byte boundary. Misaligned access will result in either SEGV or SIGBUS. There are numerous places in the multi-threaded version of stdcxx where pthread_mutex_t and/or pthread_cond_t types are contained within an union, but with an enforced alignment different than 8. All these instances must be corrected, and #ifdef-guarded for SPARCV8. Patches to follow shortly, this is just opening the issue. Warning: the patchset resolving this issue is very large, and it affects a large number of files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (STDCXX-1066) SPARCV8 requires pthread_mutex_t and pthread_cond_t to be aligned on an 8-byte boundary
[ https://issues.apache.org/jira/browse/STDCXX-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Nicoara closed STDCXX-1066. - Resolution: Duplicate Closing the issue and continuing work on STDCXX-1072. SPARCV8 requires pthread_mutex_t and pthread_cond_t to be aligned on an 8-byte boundary --- Key: STDCXX-1066 URL: https://issues.apache.org/jira/browse/STDCXX-1066 Project: C++ Standard Library Issue Type: Bug Components: Thread Safety Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x Environment: Solaris 10 Update 6 or later on SPARCV8 \[32-bit\] Defect is compiler-independent - in reality it only affects Sun Studio and GCC. Reporter: Stefan Teleman Labels: features, runtime, threads Fix For: 4.2.2, 4.2.x, 4.3.x Attachments: _config-gcc.h.stdcxx-1066.patch, _config-sunpro.h.stdcxx-1066.patch, ctype.cpp.stdcxx-1066.patch, exception.cpp.stdcxx-1066.patch, ios.cpp.stdcxx-1066.patch, iostream.cpp.stdcxx-1066.patch, iostream.stdcxx-1066.patch, locale_body.cpp.stdcxx-1066.patch, locale_classic.cpp.stdcxx-1066.patch, messages.cpp.stdcxx-1066.patch, _mutex.h.stdcxx-1066.patch, time_put.cpp.stdcxx-1066.patch, use_facet.h.stdcxx-1066.patch Starting with Solaris 10 Update 6, on SPARCV8, pthread_mutex_t and pthread_cond_t MUST be aligned on an 8-byte boundary. Misaligned access will result in either SEGV or SIGBUS. There are numerous places in the multi-threaded version of stdcxx where pthread_mutex_t and/or pthread_cond_t types are contained within an union, but with an enforced alignment different than 8. All these instances must be corrected, and #ifdef-guarded for SPARCV8. Patches to follow shortly, this is just opening the issue. Warning: the patchset resolving this issue is very large, and it affects a large number of files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (STDCXX-1071) numpunct facet cache initialization is not thread -safe
[ https://issues.apache.org/jira/browse/STDCXX-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Nicoara updated STDCXX-1071: -- Attachment: (was: patch-4.3.x.diff) numpunct facet cache initialization is not thread -safe --- Key: STDCXX-1071 URL: https://issues.apache.org/jira/browse/STDCXX-1071 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization, Thread Safety Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 Environment: $ uname -a; CC -V Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux CC: Sun C++ 5.12 Linux_i386 2011/11/16 Reporter: Liviu Nicoara Priority: Critical Labels: DCII, localization, numpunct, thread-safety Fix For: 4.2.1, 4.2.x, 4.3.x, 5.0.0 Attachments: library-reduction.cpp, patch-4.2.x.diff, patch-timings.tgz, punct-mt.cpp Original Estimate: 8h Remaining Estimate: 8h The bug affects the initialization of the cached data in numpunct facet. The failing test is 22.locale.numpunct.cpp in certain builds: Linux with SUNPro 5.12, optimized, most likely to fail. It has been reported (see linked incidents) to fail on SPARC as well. It manifests in variate ways: sometimes as heap corruption, sometimes as access violations, etc. Test cases and library reduction programs to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (STDCXX-1071) numpunct facet cache initialization is not thread -safe
[ https://issues.apache.org/jira/browse/STDCXX-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Nicoara updated STDCXX-1071: -- Attachment: patch-5.0.x.diff numpunct facet cache initialization is not thread -safe --- Key: STDCXX-1071 URL: https://issues.apache.org/jira/browse/STDCXX-1071 Project: C++ Standard Library Issue Type: Bug Components: 22. Localization, Thread Safety Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0 Environment: $ uname -a; CC -V Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux CC: Sun C++ 5.12 Linux_i386 2011/11/16 Reporter: Liviu Nicoara Priority: Critical Labels: DCII, localization, numpunct, thread-safety Fix For: 4.2.1, 4.2.x, 4.3.x, 5.0.0 Attachments: library-reduction.cpp, patch-4.2.x.diff, patch-5.0.x.diff, patch-timings.tgz, punct-mt.cpp Original Estimate: 8h Remaining Estimate: 8h The bug affects the initialization of the cached data in numpunct facet. The failing test is 22.locale.numpunct.cpp in certain builds: Linux with SUNPro 5.12, optimized, most likely to fail. It has been reported (see linked incidents) to fail on SPARC as well. It manifests in variate ways: sometimes as heap corruption, sometimes as access violations, etc. Test cases and library reduction programs to follow. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (STDCXX-1072) [Oracle Solaris/SPARCV8] stricter mutex alignment requirements
[
https://issues.apache.org/jira/browse/STDCXX-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liviu Nicoara updated STDCXX-1072:
--
Affects Version/s: (was: 4.2.0)
(was: 4.1.4)
(was: 4.1.3)
(was: 4.1.2)
5.0.0
4.3.x
4.2.x
[Oracle Solaris/SPARCV8] stricter mutex alignment requirements
--
Key: STDCXX-1072
URL: https://issues.apache.org/jira/browse/STDCXX-1072
Project: C++ Standard Library
Issue Type: Bug
Components: Thread Safety
Affects Versions: 4.2.1, 4.2.x, 4.3.x, 5.0.0
Environment: Oracle Solaris on SPARC V8 (or V9 emulation?) hardware.
Reporter: Liviu Nicoara
Labels: SPARC, Solaris, V8, alignment, mutex
Fix For: 4.2.x, 4.3.x, 5.0.0
Attachments: patch.diff
Original Estimate: 4h
Remaining Estimate: 4h
The issue has been reported in STDCXX-1066. The originator was apparently an
improvement (as a response to CR 6296770: http://tinyurl.com/8ohjsgl) shipped
with KU 137111-01 (http://tinyurl.com/ceet6ec) which requires stricter
alignment than the machine word for userland mutexes.
Quoting here the Fujitsu patch notes (in case it goes away):
{quote}
{noformat}
2) When an application using the mutex lock or rw lock in the way shown below
is executed. (*1, *2) ...
*2) ... example of programming that causes the ... problem.
In the case where the problem occurs
int *ip;
mutex_t *mp;
ip = (int *) malloc(sizeof (int) + sizeof (mutex_t));
mp = (mutex_t *) (ip + 1);
/* The address is used with a modification */
In the case where the problem does not occur -1
mutex_t mp; /* Obtained statically */
In the case where the problem does not occur -2
mutex_t *mp;
mp = (mutex_t *) malloc(sizeof (mutex_t));
/* The address is used without any modifications */
{noformat}
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
