[Bug libstdc++/63614] New: With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[Bug libstdc++/63614] New: With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[dyle at dyle dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63614

            Bug ID: 63614
           Summary: With gcc-4.8.3 and -stdgnu++0x call to
                    std::this_thread::get_id() creates SIGSEV
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dyle at dyle dot org

Things have worked recently until I run into a SIGSEV rigtht in the guts of
std::this_thread::id(). I tried several compiler options but still the program
crashes.

The whole compiler line within a cmake projekt for my sources causing the crash
read:

...
[ 56%] Building CXX object
bin/modules/qkd-hardware-pickup/CMakeFiles/qkd-hardware-pickup.dir/qkd-hardware-pickup-alice.cpp.o
cd /home/dyle/doc/src/ait/qkd/build/bin/modules/qkd-hardware-pickup &&
/usr/bin/c++   -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB
-DQT_NO_DEBUG -DQT_XML_LIB -DVERSION=\"9.9999.2\" -D_BSD_SOURCE -D_GNU_SOURCE
-std=gnu++0x -Werror -Wall -Wextra -pedantic -g -ggdb3 -rdynamic -O3
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -isystem /usr/include/qt4
-isystem /usr/include/qt4/QtGui -isystem /usr/include/qt4/QtDBus -isystem
/usr/include/qt4/QtXml -isystem /usr/include/qt4/QtNetwork -isystem
/usr/include/qt4/QtCore -I/usr/include/qwt6 -I/home/dyle/doc/src/ait/qkd/build
-I/home/dyle/doc/src/ait/qkd -I/home/dyle/doc/src/ait/qkd/include
-I/home/dyle/doc/src/ait/qkd/build/bin/modules/qkd-hardware-pickup    -o
CMakeFiles/qkd-hardware-pickup.dir/qkd-hardware-pickup-alice.cpp.o -c
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp
/usr/bin/cmake -E cmake_progress_report
/home/dyle/doc/src/ait/qkd/build/CMakeFiles
...


This is then gdb:


GNU gdb (Gentoo 7.8 vanilla) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
bin/modules/qkd-hardware-pickup/qkd-hardware-pickup...done.

warning: core file may not match specified executable file.
[New LWP 27565]
[New LWP 27561]
[New LWP 27564]
[New LWP 27562]
[New LWP 27554]
[New LWP 27560]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/dyle/doc/src/ait/qkd/build/bin/qkd-hardware-pickup
--debug-core-presiftin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __gthread_self () at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/x86_64-pc-linux-gnu/bits/gthr-default.h:686
686       return __gthrw_(pthread_self) ();
(gdb) bt
#0  __gthread_self () at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/x86_64-pc-linux-gnu/bits/gthr-default.h:686
#1  get_id () at
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/thread:252
#2  qkd_hardware_pickup_alice::presifter (this=0x1f1fbc0) at
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1195
#3  0x00007f9f31cdd5e0 in std::(anonymous
namespace)::execute_native_thread_routine (__p=<optimized out>) at
/var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/src/c++11/thread.cc:84
#4  0x00007f9f31f38073 in start_thread (arg=0x7f9f26193700) at
pthread_create.c:309
#5  0x00007f9f314624ad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) list
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:1195
1190     * 
1191     * here the presift calculation starts
1192     */
1193    void qkd_hardware_pickup_alice::presifter() {
1194        
1195        std::thread::id nThreadId = std::this_thread::get_id();
1196
1197        // this method is run at start by PRESIFT_THREADS concurrent
threads
1198        if (debug_core_presifting()) {
1199            qkd::utility::debug(true) << 

The thread itself is created at line 622, here:

(gdb) list
/home/dyle/doc/src/ait/qkd/bin/modules/qkd-hardware-pickup/qkd-hardware-pickup-alice.cpp:622
617         
618         set_role((unsigned long)qkd::module::module_role::ROLE_ALICE);
619         
620         // launch worker threads
621         d->cPusher = std::thread([this]{ pusher(); });
622         for (int i = 0; i < PRESIFT_THREADS; ++i) d->cPresifter[i] =
std::thread([this]{ presifter(); });
623         
624         // wind down worker threads when termination signal emitted
625         connect(this, SIGNAL(terminated()), SLOT(stop_worker_threads()));
626     }


This is compiled with -stdgnu++0x.

Is this a gcc bug? Is it possible that std::this_thread::get_id() SIGSEVs?

Maybe it is due to my way of creating threads via lambda expression like this
in class A constructor:


$ cat t.cpp 
#include <iostream>
#include <thread>


class A {

public:

    std::thread t;
    A() {
        t = std::thread([this]{ foo(); });
    }

private:

    void foo() {
        std::this_thread::sleep_for(std::chrono::seconds(1));
        std::cout << "A::foo() - " << std::this_thread::get_id() << std::endl;
    }
};


int main() {

    A a;
    std::this_thread::sleep_for(std::chrono::seconds(1));
    std::cout << "main() - " << std::this_thread::get_id() << std::endl;

    a.t.join();

    return 0;
}

$ g++ -std=gnu++0x -pthread t.cpp
$ ./a.out 
main() - 140454910891840
A::foo() - 140454894458624

(Yes, there's a race condition on std::cout. But this is not the point.) Is
there a drawback by creating a threads that way and could there be any
correlation to my sigsev?

An then: -pthread is missing in the crashing program. But it crashes with it as
well.

Is there any remedy? Or is this not a gcc bug at all?

[Bug libstdc++/63614] With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63614

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to dyle from comment #0)
> Is this a gcc bug? Is it possible that std::this_thread::get_id() SIGSEVs?

Yes it's possible if you don't use -pthread to link to libpthread.

> (Yes, there's a race condition on std::cout. But this is not the point.) Is
> there a drawback by creating a threads that way and could there be any
> correlation to my sigsev?

No, it's unlikely.

You can rule that out by using std::thread(&A::foo, this)

(In reply to dyle from comment #1)
> Huh. It ain't std::this_thread::get_id(), it is the assignment! 
> Because this 
> 
>     auto nThread = 1;
> 
> as first statement in the thread crashes also. o.O

Then that's unlikely to be a GCC bug, are you running out of stack, or
scribbling on the stack from another function?

Have you tried using valgrind, or asan, or -fstack-protector ?

[Bug libstdc++/63614] With gcc-4.8.3 and -stdgnu++0x call to std::this_thread::get_id() creates SIGSEV

[dyle at dyle dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63614

--- Comment #3 from dyle at dyle dot org ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to dyle from comment #0)
> > Is this a gcc bug? Is it possible that std::this_thread::get_id() SIGSEVs?
> 
> Yes it's possible if you don't use -pthread to link to libpthread.

Ok. I'll attach it then.

> > (Yes, there's a race condition on std::cout. But this is not the point.) Is
> > there a drawback by creating a threads that way and could there be any
> > correlation to my sigsev?
> 
> No, it's unlikely.
> 
> You can rule that out by using std::thread(&A::foo, this)

Good, I'll use this pattern then. I do not sense any pros/cons compared to my
previous lambda approach.


> (In reply to dyle from comment #1)
> > Huh. It ain't std::this_thread::get_id(), it is the assignment! 
> > Because this 
> > 
> >     auto nThread = 1;
> > 
> > as first statement in the thread crashes also. o.O
> 
> Then that's unlikely to be a GCC bug, are you running out of stack, or
> scribbling on the stack from another function?

Not that I'm aware of. I always try to be extra cautious and super paranoid,
hence my compiler flags: -Wall -Wextra -Werror -pedantic. But these ain't no
silver bullets either.

> Have you tried using valgrind, or asan, or -fstack-protector ?

Good idea. I'll go for these tomorrow.

Thx.