Created: (STDCXX-1040) Solaris 10 Kernel Update 137111-01 patches

Solaris 10 Kernel Update 137111-01 patches
------------------------------------------

                 Key: STDCXX-1040
                 URL: https://issues.apache.org/jira/browse/STDCXX-1040
             Project: C++ Standard Library
          Issue Type: Improvement
          Components: Build and Installation
    Affects Versions: 4.2.1, 4.2.0
         Environment: Solaris 10 10/2008 SPARC, Kernel Update 137111-01
            Reporter: Martin Sebor
            Priority: Critical
             Fix For: 4.2.2


Quoting from this [post | http://markmail.org/message/xkvvd4xw2gyqzjip]:
{quote}
Solaris 10 10/2008 SPARC has introduced a binary incompatible change
in the POSIX and Solaris threads implementation:

http://docs.sun.com/app/docs/doc/820-5245/chapter2-1000?a=view

{panel}

Objects of type {{mutex_t}} and {{pthread_mutex_t}} must start at 8-byte
aligned addresses. Applications that do not satisfy this requirement
fail. The following error message is displayed:

\*\*\* {{_THREAD_ERROR_DETECTION}}: lock usage error detected \*\*\*
...
"mutex is misaligned"
OR:
"condvar is misaligned"

{panel}

In reality, the run-time performance is much worse than the errata
above claims: misaligned mutexes or conditional variables cause the
program to spuriously {{SEGV}} in sometimes hard to reproduce ways [
Heisenbug ].

You can view full details of this bug/change here:

http://bugs.opensolaris.org/view_bug.do?bug_id=6729759

To make a long story short, Solaris Kernel Update 137111-01 introduced
an ABI incompatible implementation restriction, requiring that mutexes
and conditional variables must be 8-byte aligned. This restriction has
never been documented, nor has it ever been enforced, until Solaris 10
10/2008 [ Solaris Kernel Update 137111-01 ].

The consequence of this KU is that, the multi-threaded 32-bit SPARC
version of the Apache Standard C++ Library [ 4.2.1 ] will no longer
work, and will fail at run-time with seemingly unexplainable crashes [
the exact same build will work on Solaris versions prior to Kernel
Update 137111-01 ].

This problem is not specific to the Apache Standard C++ Library: it
will occur with any 32-bit SPARCV8 binaries which do not align mutexes
or conditional variables on an 8 byte boundary.

I have created a set of patches for the Apache Standard C++ Library,
Version 4.2.1, for this problem:

http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/

You can download the tarball with all the patches from the same URL:

http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/stdcxx-upstream-patches.tar.bz2

These patches force an 8-byte alignment for all objects which contain
a mutex or a conditional variable, and that only for SPARC. With these
patches, all the tests perform as expected.

The patch {{22.locale.numpunct.cpp.43.diff}} is not related to the SPARCV8
ABI change -- it is simply an avoidance of a {{SEGV}} in case the variable
{{first_non_c == NULL}} [ Solaris sprintf(3C) SEGV's on {{NULL char*}}
arguments ].
{quote}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/STDCXX-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Sebor updated STDCXX-1040:
---------------------------------

    Attachment: stdcxx-upstream-patches.tar.bz2

Attached [Stefan Teleman's|mailto:stefan.teleman@...] patches.

> Solaris 10 Kernel Update 137111-01 patches
> ------------------------------------------
>
>                 Key: STDCXX-1040
>                 URL: https://issues.apache.org/jira/browse/STDCXX-1040
>             Project: C++ Standard Library
>          Issue Type: Improvement
>          Components: Build and Installation
>    Affects Versions: 4.2.0, 4.2.1
>         Environment: Solaris 10 10/2008 SPARC, Kernel Update 137111-01
>            Reporter: Martin Sebor
>            Priority: Critical
>             Fix For: 4.2.2
>
>         Attachments: stdcxx-upstream-patches.tar.bz2
>
>
> Quoting from this [post | http://markmail.org/message/xkvvd4xw2gyqzjip]:
> {quote}
> Solaris 10 10/2008 SPARC has introduced a binary incompatible change
> in the POSIX and Solaris threads implementation:
> http://docs.sun.com/app/docs/doc/820-5245/chapter2-1000?a=view
> {panel}
> Objects of type {{mutex_t}} and {{pthread_mutex_t}} must start at 8-byte
> aligned addresses. Applications that do not satisfy this requirement
> fail. The following error message is displayed:
> \*\*\* {{_THREAD_ERROR_DETECTION}}: lock usage error detected \*\*\*
> ...
> "mutex is misaligned"
> OR:
> "condvar is misaligned"
> {panel}
> In reality, the run-time performance is much worse than the errata
> above claims: misaligned mutexes or conditional variables cause the
> program to spuriously {{SEGV}} in sometimes hard to reproduce ways [
> Heisenbug ].
> You can view full details of this bug/change here:
> http://bugs.opensolaris.org/view_bug.do?bug_id=6729759
> To make a long story short, Solaris Kernel Update 137111-01 introduced
> an ABI incompatible implementation restriction, requiring that mutexes
> and conditional variables must be 8-byte aligned. This restriction has
> never been documented, nor has it ever been enforced, until Solaris 10
> 10/2008 [ Solaris Kernel Update 137111-01 ].
> The consequence of this KU is that, the multi-threaded 32-bit SPARC
> version of the Apache Standard C++ Library [ 4.2.1 ] will no longer
> work, and will fail at run-time with seemingly unexplainable crashes [
> the exact same build will work on Solaris versions prior to Kernel
> Update 137111-01 ].
> This problem is not specific to the Apache Standard C++ Library: it
> will occur with any 32-bit SPARCV8 binaries which do not align mutexes
> or conditional variables on an 8 byte boundary.
> I have created a set of patches for the Apache Standard C++ Library,
> Version 4.2.1, for this problem:
> http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/
> You can download the tarball with all the patches from the same URL:
> http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/stdcxx-upstream-patches.tar.bz2
> These patches force an 8-byte alignment for all objects which contain
> a mutex or a conditional variable, and that only for SPARC. With these
> patches, all the tests perform as expected.
> The patch {{22.locale.numpunct.cpp.43.diff}} is not related to the SPARCV8
> ABI change -- it is simply an avoidance of a {{SEGV}} in case the variable
> {{first_non_c == NULL}} [ Solaris sprintf(3C) SEGV's on {{NULL char*}}
> arguments ].
> {quote}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/STDCXX-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Sebor reassigned STDCXX-1040:
------------------------------------

    Assignee: Martin Sebor

> Solaris 10 Kernel Update 137111-01 patches
> ------------------------------------------
>
>                 Key: STDCXX-1040
>                 URL: https://issues.apache.org/jira/browse/STDCXX-1040
>             Project: C++ Standard Library
>          Issue Type: Improvement
>          Components: Build and Installation
>    Affects Versions: 4.2.0, 4.2.1
>         Environment: Solaris 10 10/2008 SPARC, Kernel Update 137111-01
>            Reporter: Martin Sebor
>            Assignee: Martin Sebor
>            Priority: Critical
>             Fix For: 4.2.2
>
>         Attachments: stdcxx-upstream-patches.tar.bz2
>
>
> Quoting from this [post | http://markmail.org/message/xkvvd4xw2gyqzjip]:
> {quote}
> Solaris 10 10/2008 SPARC has introduced a binary incompatible change
> in the POSIX and Solaris threads implementation:
> http://docs.sun.com/app/docs/doc/820-5245/chapter2-1000?a=view
> {panel}
> Objects of type {{mutex_t}} and {{pthread_mutex_t}} must start at 8-byte
> aligned addresses. Applications that do not satisfy this requirement
> fail. The following error message is displayed:
> \*\*\* {{_THREAD_ERROR_DETECTION}}: lock usage error detected \*\*\*
> ...
> "mutex is misaligned"
> OR:
> "condvar is misaligned"
> {panel}
> In reality, the run-time performance is much worse than the errata
> above claims: misaligned mutexes or conditional variables cause the
> program to spuriously {{SEGV}} in sometimes hard to reproduce ways [
> Heisenbug ].
> You can view full details of this bug/change here:
> http://bugs.opensolaris.org/view_bug.do?bug_id=6729759
> To make a long story short, Solaris Kernel Update 137111-01 introduced
> an ABI incompatible implementation restriction, requiring that mutexes
> and conditional variables must be 8-byte aligned. This restriction has
> never been documented, nor has it ever been enforced, until Solaris 10
> 10/2008 [ Solaris Kernel Update 137111-01 ].
> The consequence of this KU is that, the multi-threaded 32-bit SPARC
> version of the Apache Standard C++ Library [ 4.2.1 ] will no longer
> work, and will fail at run-time with seemingly unexplainable crashes [
> the exact same build will work on Solaris versions prior to Kernel
> Update 137111-01 ].
> This problem is not specific to the Apache Standard C++ Library: it
> will occur with any 32-bit SPARCV8 binaries which do not align mutexes
> or conditional variables on an 8 byte boundary.
> I have created a set of patches for the Apache Standard C++ Library,
> Version 4.2.1, for this problem:
> http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/
> You can download the tarball with all the patches from the same URL:
> http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/stdcxx-upstream-patches.tar.bz2
> These patches force an 8-byte alignment for all objects which contain
> a mutex or a conditional variable, and that only for SPARC. With these
> patches, all the tests perform as expected.
> The patch {{22.locale.numpunct.cpp.43.diff}} is not related to the SPARCV8
> ABI change -- it is simply an avoidance of a {{SEGV}} in case the variable
> {{first_non_c == NULL}} [ Solaris sprintf(3C) SEGV's on {{NULL char*}}
> arguments ].
> {quote}

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.