This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: std thread,mutex,cv and static linking with GCC


On 16 November 2014 01:04, Szabolcs Nagy wrote:
> * Jonathan Wakely <jwakely.gcc@gmail.com> [2014-10-22 18:10:07 +0100]:
>> On 22 October 2014 16:40, Damian Lezama wrote:
>> > Hi,
>> >
>> > I was getting random crashes when using thread, mutex, and cv and statically linking my project. Some of the libraries I link against use pthread, so I narrowed the issue down to this test:
>> >
>> > I statically link a simple test that uses thread, mutex, and cv like this: "g++ --std=c++11 -pthread -static test.cc" and  I get this when I run it:
>> >
>> > terminate called after throwing an instance of 'std::system_error'
>> >   what():  Enable multithreading to use std::thread: Operation not permitted
>> > Aborted
>> >
>> > Everything works fine if I don't use -static, the problem is specific to static linking. If in my test I use pthread directly to create a thread, then it runs and creating an std::thread also works, but the test crashes when using the cv. My theory is that the linker is being lazy (weak references? optimization?) and the pthread stuff std needs is not included in the binary unless referenced somewhere else. In real projects this is quite dangerous because having dependencies that use most of the pthread stuff makes these crashes rare (I caught this problem with a stress test).
>> >
>> > Any ideas? Is this s bug in the library?
>>
>> Yes, your theory is basically correct.
>>
>> Some GNU/Linux distributions (at least Fedora and Red Hat and its
>> clones) have some custom modifications to libpthread.a that ensures
>> linking statically works. I don't remember the details.
>>
>> An alternative that might help is to use something like
>> -Wl,--whole-archive -lpthread -Wl,--no-whole-archive to link in
>> everything from libpthread.
>>
>> Finally, I believe the problem is solved in the current GCC trunk (at
>> least on GNU/Linux) by a change I made to std::thread that adds an
>> explicit dependency on pthread_create, which should force libpthread
>> to be linked to. I think that might have been backported to the Debian
>> and/or Ubuntu packages for GCC 4.8 and 4.9.
>
> sorry, i'm late to this but fixing std::thread is not enough,
> the weak alias magic in libgcc/gthr-posix.h is not guaranteed to work
>
> there are several bugs here:
>
> 1) fallback code (unknown posix systems) should assume threaded
> application (that's the safest bet)
>
> 2) determining threadedness with weak alias magic is broken for dynamic
> loading and static linking as well (dlopened library can pull in pthread
> dependency at runtime, and the prescence of one symbol says nothing
> about other symbols with static linking)
>
> 3) using symbols through weak aliases at runtime is wrong with static
> linking (it just happens to work by chance with the redhat libpthread.a
> has a single .o hack)
>
> see this analysis for more details and crashing example code:
>
> http://www.openwall.com/lists/musl/2014/10/18/5

I agree, but these issues with gthr-posix.h should probably be
discussed on the main GCC list, as that header is not owned by
libstdc++ and needs wider involvement for any changes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]