Solaris 11 Sparc crash in std::call_once

Solaris 11 Sparc crash in std::call_once

[Jeffrey Walton]

Hi everyone,

I have some boilerplate call_once code that sets a few function pointers:

    std::once_flag s_flag;
    InitializeInteger::InitializeInteger()
    {
        std::call_once(s_flag, []() {
            SetFunctionPointers();
        });
    }

I can duplicate the crash on Linux if I don't use -pthread. The back
traces on Solaris and Linux look exactly the same when inducing the
crash on Linux.

The code is crashing on Solaris 11 Sparc. According to
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html,
I need -pthread and it was provided during compile and link. The
concurrency pages also states (under Threads):

    Requisite command-line flags are used for atomic operations
    and threading. Examples of this include -pthread and
    -march=native, although specifics vary depending on the host
    environment. See Command Options and Machine Dependent Options.

We can't use -march=native because it breaks distros model of distribution.

I checked both Command Options and Machine Dependent Options and
nothing jumped out at me, but I know very little about Sparc
architecture.

My question is, are other flags required on Sparc?

Thanks in advance.

==========

(gdb) bt full
#0  0x00000001005be6a8 in
std::call_once<InitializeInteger::InitializeInteger()::<lambda()> >
(__once=...,
    __f=<unknown type in /home/test/cryptest.exe, CU 0x93609c, DIE
0x97266d>) at /usr/gcc/7/include/c++/7.3.0/mutex:676
        __callable = {__(float) = @0xffffffff7fffdf27}
#1  CryptoPP::InitializeInteger::InitializeInteger (
    this=this@entry=0xffffffff7fffe170) at integer.cpp:112
No locals.
#2  0x00000001005c5d8c in Integer::Integer (this=0xffffffff7fffe170,
    encodedInteger=0x1009e5700
"\212\252\346){l\260FB\253[\axQ(N\267\022\217\032\212\252\346){l\260FB\253[\axQ(N\267\022\217\032\212\252\346){l\260FB\253[\axQ(N\267\022\217\032\212\252",
<incomplete sequence \346\051>, byteCount=64,
    s=<optimized out>, o=<optimized out>) at integer.cpp:3019
No locals.
...

==========

Solaris 11 Sparc GCC info; crashes with -pthread:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/gcc/7/lib/gcc/sparcv9-solaris2.11/7.3.0/lto-wrapper
Target: sparcv9-solaris2.11
Configured with:
/builds/ul11u3sru-gate/components/gcc7/gcc-7.3.0/configure
--prefix=/usr/gcc/7 --mandir=/usr/gcc/7/share/man
--bindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
--sbindir=/usr/gcc/7/sbin --infodir=/usr/gcc/7/share/info
--libexecdir=/usr/gcc/7/lib --enable-languages=c,c++,fortran,objc
--enable-shared --enable-initfini-array --disable-rpath
--with-system-zlib --with-build-config=no
--with-gmp-include=/usr/include/gmp
--with-mpfr-include=/usr/include/mpfr --without-gnu-ld
--with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as
'BOOT_CFLAGS=-g -O2' sparcv9-solaris2.11
Thread model: posix
gcc version 7.3.0 (GCC)

==========

Here is typical compile and link. We use the same flags for each, and
drive link through the compiler.

$ gmake
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -c cryptlib.cpp
...
g++ -o cryptest.exe -DNDEBUG -g2 -O3 -fPIC -pthread -pipe test.o
<other objects> ./libcryptopp.a  -lnsl -lsocket

Re: Solaris 11 Sparc crash in std::call_once

[Jonathan Wakely]

On Tue, 21 Aug 2018 at 10:08, Jeffrey Walton wrote:
> The code is crashing on Solaris 11 Sparc.

What kind of crashing? Segfault? Bus error?

Re: Solaris 11 Sparc crash in std::call_once

[Jeffrey Walton]

On Tue, Aug 21, 2018 at 5:10 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On Tue, 21 Aug 2018 at 10:08, Jeffrey Walton wrote:
>> The code is crashing on Solaris 11 Sparc.
>
> What kind of crashing? Segfault? Bus error?

My bad, on Solaris it is a SIGSEGV:

(gdb) r v
...

[New Thread 1 (LWP 1)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00000001005be6a8 in
std::call_once<InitializeInteger::InitializeInteger()::<lambda()> >
(__once=...,
    __f=<unknown type in /home/test/cryptest.exe, CU 0x93609c, DIE
0x97266d>) at /usr/gcc/7/include/c++/7.3.0/mutex:676
676           __once_callable = std::__addressof(__callable);

On Linux without -pthread the code throws a std::system_error at the same place.

Jeff

Re: Solaris 11 Sparc crash in std::call_once

[Jeffrey Walton]

On Tue, Aug 21, 2018 at 5:14 AM, Jeffrey Walton <noloader@gmail.com> wrote:
> On Tue, Aug 21, 2018 at 5:10 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On Tue, 21 Aug 2018 at 10:08, Jeffrey Walton wrote:
>>> The code is crashing on Solaris 11 Sparc.
>>
>> What kind of crashing? Segfault? Bus error?
>
> My bad, on Solaris it is a SIGSEGV:
>
> (gdb) r v
> ...
>
> [New Thread 1 (LWP 1)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1 (LWP 1)]
> 0x00000001005be6a8 in
> std::call_once<InitializeInteger::InitializeInteger()::<lambda()> >
> (__once=...,
>     __f=<unknown type in /home/test/cryptest.exe, CU 0x93609c, DIE
> 0x97266d>) at /usr/gcc/7/include/c++/7.3.0/mutex:676
> 676           __once_callable = std::__addressof(__callable);

I probably should have provided this again. The __callable and
0xffffffff7fffdf27 looks odd assuming it is an address:

(gdb) bt full
#0  0x00000001005be6a8 in
std::call_once<InitializeInteger::InitializeInteger()::<lambda()> >
(__once=...,
    __f=<unknown type in /home/jeff/cryptopp/cryptest.exe, CU
0x93609c, DIE 0x97266d>) at /usr/gcc/7/include/c++/7.3.0/mutex:676
        __callable = {__(float) = @0xffffffff7fffdf27}
#1  InitializeInteger::InitializeInteger (
    this=this@entry=0xffffffff7fffe170) at integer.cpp:112
No locals.

Re: Solaris 11 Sparc crash in std::call_once

[Jeffrey Walton]

On Tue, Aug 21, 2018 at 5:08 AM, Jeffrey Walton <noloader@gmail.com> wrote:
> Hi everyone,
>
> I have some boilerplate call_once code that sets a few function pointers:
>
>     std::once_flag s_flag;
>     InitializeInteger::InitializeInteger()
>     {
>         std::call_once(s_flag, []() {
>             SetFunctionPointers();
>         });
>     }

Cancel... It looks like there are a lot of bad interactions with
libstdc++, glibc and pthreads. Cf.,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146.

We are going to move onto to something else. Since we are only writing
function pointers an old doubled-checked init should work fine. It
does not matter if the function pointer gets written twice during the
first race (if it occurs).

Jeff