Segmentation fault in std::thread::id's std::operator==

Question

I have encountered an issue which I am not sure how to resolve. I believe it's an issue in GCC and/or libstdc++.

I am running Ubuntu 14.04 LTS with GCC 4.8.2-19ubuntu1, libstdc++3.4.19 (I believe? How do you find what version of libstdc++ library is installed on your linux machine?), and boost 1.55.

Here's the code:

// http://www.boost.org/doc/libs/1_54_0/libs/log/doc/html/log/tutorial.html
// with a slight modification to ensure we're testing with threads too
// g++ -g -O0 --std=c++11 staticlinktest.cpp -lboost_log_setup -lboost_log -lboost_system -lboost_filesystem -lboost_thread -lpthread

#define BOOST_ALL_DYN_LINK 1

#include <boost/log/trivial.hpp>

#include <thread>
#include <atomic>
#include <vector>

int main(int, char*[])
{
    BOOST_LOG_TRIVIAL(trace) << "A trace severity message";
    BOOST_LOG_TRIVIAL(debug) << "A debug severity message";
    BOOST_LOG_TRIVIAL(info) << "An informational severity message";
    BOOST_LOG_TRIVIAL(warning) << "A warning severity message";
    BOOST_LOG_TRIVIAL(error) << "An error severity message";
    BOOST_LOG_TRIVIAL(fatal) << "A fatal severity message";

    std::atomic<bool> exiting(false);
    std::vector<std::thread> threads;
    for ( int i = 0; i < 8; ++i ) {
        threads.push_back(std::thread([&exiting](){
            while (!exiting)
                BOOST_LOG_TRIVIAL(trace) << "thread " << std::this_thread::get_id() << " trace";
        }));
    }

    usleep(1000000);
    exiting = true;
    std::for_each(threads.begin(), threads.end(), [](std::thread& t){
        t.join();
    });

    return 0;
}

The issue: Using the command line at the top, I would build with dynamic linking. Everything seems to work great. I see apparently-valid output complete with thread IDs and tracing information.

However, in my project I need to be able to use static linking. So I add in the "-static" switch to the g++ command, and comment out the #define for BOOST_ALL_DYN_LINK. It builds just fine. But when I execute the program, it runs up until the first thread gets created, then segfaults. The backtrace seems to always be the same:

#0  0x0000000000000000 in ?? ()
#1  0x0000000000402805 in __gthread_equal (__t1=140737354118912, __t2=0) at /usr/include/x86_64-linux-gnu/c++/4.8/bits/gthr-default.h:680
#2  0x0000000000404116 in std::operator== (__x=..., __y=...) at /usr/include/c++/4.8/thread:84
#3  0x0000000000404c03 in std::operator<< <char, std::char_traits<char> > (__out=..., __id=...) at /usr/include/c++/4.8/thread:234
#4  0x000000000040467e in boost::log::v2s_mt_posix::operator<< <char, std::char_traits<char>, std::allocator<char>, std::thread::id> (strm=..., 
    value=...) at /usr/include/boost/log/utility/formatting_ostream.hpp:710
#5  0x0000000000402939 in __lambda0::operator() (__closure=0x7bb5e0) at staticlinktest.cpp:27
#6  0x0000000000403ea8 in std::_Bind_simple<main(int, char**)::__lambda0()>::_M_invoke<>(std::_Index_tuple<>) (this=0x7bb5e0)
    at /usr/include/c++/4.8/functional:1732
#7  0x0000000000403dff in std::_Bind_simple<main(int, char**)::__lambda0()>::operator()(void) (this=0x7bb5e0)
    at /usr/include/c++/4.8/functional:1720
#8  0x0000000000403d98 in std::thread::_Impl<std::_Bind_simple<main(int, char**)::__lambda0()> >::_M_run(void) (this=0x7bb5c8)
    at /usr/include/c++/4.8/thread:115
#9  0x000000000047ce60 in execute_native_thread_routine ()
#10 0x000000000042a962 in start_thread (arg=0x7ffff7ffb700) at pthread_create.c:312
#11 0x00000000004e5ba9 in clone ()

It looks to me as if it's trying to call a null function pointer and only when linked statically. Any thoughts? Am I doing something wrong?

"issue in GCC and/or libstdc++" - while it can happen, this is almost never the case. Always look for the problem in your own code first. — lethal-guitar, May 06 '14 at 21:12

score 7 · Accepted Answer · edited May 23 '17 at 10:33

Statically linking libpthread into your applications is a really bad idea.

Nevertheless, here is how to do it.

I first fixed the compile errors (I suspect that you aren't showing us the code that you are actually compiling, or boost pollutes the namespace that much), then removed the irrelevant boost stuff, that only adds noise to the question. Here is the code:

#include <atomic>
#include <chrono>
#include <iostream>
#include <thread>
#include <vector>

int main(int, char*[])
{
    std::atomic<bool> exiting(false);

    std::vector<std::thread> threads;
    for ( int i = 0; i < 8; ++i ) {
        threads.push_back(std::thread([&exiting](){
            while (!exiting)
                std::cout << "thread " << std::this_thread::get_id() << " trace\n";
        }));
    }

    std::this_thread::sleep_for(std::chrono::milliseconds(1));

    exiting = true;

    for(auto& t : threads){
        t.join();
    };

    return 0;
}

It runs fine if I dynamically link but crashes when statically linked:

terminate called after throwing an instance of 'std::system_error'
  what():  Operation not permitted
Aborted (core dumped)

According to this e-mail the libstdc++ has to be configured appropriately if you use threads and statically link. Here are the magic flags to make it work with static linking:

g++ -std=c++11 -pedantic -pthread threads.cpp -static -Wl,--whole-archive -lpthread -Wl,--no-whole-archive

As I said before, statically linking libpthread into your application is asking for trouble.

The code in the question is actually a copy/paste in its entirety from a file I sent to a coworker and does compile just fine over here. Nonetheless, it's nice to know that wrapping -lpthread in --whole-archive seems to have done the trick. Your link mentioned --enable-tls; I take it that would require rebuilding GCC? — inetknght, May 06 '14 at 21:21
I suppose this also means that this crash would also resolved if I dynamically linked to pthreads? — inetknght, May 06 '14 at 21:23
@inetknght Probably yes, that would be my first guess. In any case, I would link pthreads dynamically. — Ali, May 06 '14 at 21:25

Segmentation fault in std::thread::id's std::operator==

1 Answers1

Linked