Segfault podczas inicjalizacji statycznej podczas łączenia budowanego przez gcc Boost w skompilowany program Intel C++.

Question

Mam system Ubuntu 13.04 z najnowszą wersją SVN bibliotek Boost C++. Instalacja Boost została zbudowana przy użyciu natywnej wersji systemu gcc, v4.7.3. Używam Boost dość intensywnie i działa bardzo dobrze, gdy kompiluję używając gcc; Użyłem wielu z nich, w tym Boost.Thread (o którym będę mówić więcej poniżej), bez żadnych problemów.

Mój problem występuje, gdy próbuję zbudować program przy użyciu kompilatora Intel C++ (osobiście użyłem kilku różnych wersji w serii v13.x), które łączą się z zainstalowanymi bibliotekami boost. Kiedy to zrobię, otrzymuję błąd segmentacji natychmiast po uruchomieniu programu; wydaje się, że występuje podczas statycznej inicjalizacji biblioteki Boost.Thread. Oto prosty przykład programu:

#include <boost/version.hpp> 
#include <boost/thread.hpp> 

int main() 
{ 
    boost::this_thread::sleep(boost::posix_time::seconds(1)); 
} 

skompilować go przy użyciu Intel C++:

icpc test.cc -lboost_thread -lboost_system -I/path/to/boost/inc/dir -L/path/to/boost/lib/dir 

Jak powiedziałem, kiedy biegnę wynikowy programu, pojawia się niemal natychmiastowe segfault. Via gdb, ślad stosu od punktu segfault jest następujący:

#0 0x00007ffff79b6351 in boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()() from ./libboost_thread.so.1.55.0 
#1 0x00007ffff79b02e1 in _GLOBAL__sub_I_thread.cpp() from ./libboost_thread.so.1.55.0 
#2 0x00007ffff7de9876 in call_init (l=l@entry=0x7ffff7ff9a10, argc=argc@entry=1, 
    argv=argv@entry=0x7fffffffe0b8, env=env@entry=0x7fffffffe0c8) at dl-init.c:84 
#3 0x00007ffff7de9930 in call_init (env=<optimized out>, argv=<optimized out>, 
    argc=<optimized out>, l=0x7ffff7ff9a10) at dl-init.c:55 
#4 _dl_init (main_map=0x7ffff7ffe268, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8) 
    at dl-init.c:133 
#5 0x00007ffff7ddb68a in _dl_start_user() from /lib64/ld-linux-x86-64.so.2 
#6 0x0000000000000001 in ??() 
#7 0x00007fffffffe391 in ??() 
#8 0x0000000000000000 in ??() 

Nie bardzo pouczające, ale to wyraźnie umiera podczas inicjalizacji libboost_thread.so. Gdybym odbudować Boost, w tym symboli debugowania, a następnie uzyskać nieco lepszy obraz:

#0 shared_count (r=..., this=0x7ffff7bbc5f8 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep+8>) 
    at ./boost/smart_ptr/shared_ptr.hpp:328 
#1 shared_ptr (this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>) at ./boost/smart_ptr/shared_ptr.hpp:328 
#2 exception_ptr (ptr=..., this=0x7ffff7bbc5f0 <boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>()::ep>) 
    at ./boost/exception/detail/exception_ptr.hpp:53 
#3 boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>() at ./boost/exception/detail/exception_ptr.hpp:130 
#4 0x00007ffff79b02e1 in __static_initialization_and_destruction_0 (__initialize_p=<optimized out>, __priority=<optimized out>) at ./boost/exception/detail/exception_ptr.hpp:143 
#5 _GLOBAL__sub_I_thread.cpp(void)() at libs/thread/src/pthread/thread.cpp:767 
#6 0x00007ffff7de9876 in call_init (l=l@entry=0x7ffff7ff9a10, argc=argc@entry=1, argv=argv@entry=0x7fffffffe0b8, env=env@entry=0x7fffffffe0c8) at dl-init.c:84 
#7 0x00007ffff7de9930 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=0x7ffff7ff9a10) at dl-init.c:55 
#8 _dl_init (main_map=0x7ffff7ffe268, argc=1, argv=0x7fffffffe0b8, env=0x7fffffffe0c8) at dl-init.c:133 
#9 0x00007ffff7ddb68a in _dl_start_user() from /lib64/ld-linux-x86-64.so.2 
#10 0x0000000000000001 in ??() 
#11 0x00007fffffffe391 in ??() 
#12 0x0000000000000000 in ??() 

Jest dla mnie jasne, co statyczne/globalne obiektu powoduje problem występuje, więc nie jestem pewien, jak postępować. Powieliłem to zachowanie, używając wielu wersji Boost i kilku różnych wersji kompilatora Intel C++ w serii v13.x, która jest jedyną wersją, do której mam dostęp w tej chwili. Próbowałem każdej permutacji kompilatora (tj. Zbudowałem Boost z zarówno gcc i icpc i zbudowałem moją aplikację testową z obu również); jedyną permutacją, która się nie powiedzie jest Boost zbudowany z gcc, a moja aplikacja testowa jest zbudowana przy użyciu icpc. W każdym innym przypadku aplikacja testowa działa poprawnie.

Z powiedział, że może być doprowadzone do oczywistej odpowiedzi:

• Dlaczego nie po prostu odbudować Boost, korzystając icpc i nazywają to dzień? To podejście wydaje się być skuteczne, biorąc pod uwagę moje eksperymenty, ale mam klientów, którzy lubią używać icpc do budowania mojego oprogramowania. Ci sami klienci prawdopodobnie będą mieć zainstalowany pakiet dystrybucji Boost pod Linuxem; nie mają żadnej kontroli nad środowiskiem kompilacji, które zostało użyte do wygenerowania tego pakietu (i, wedle wszelkiego prawdopodobieństwa, zostało skompilowane przy użyciu i). Dlatego, jeśli możliwe jest wsparcie takiej konfiguracji mieszanego kompilatora, byłoby to optymalne.

Czy ktoś ma jakieś wskazówki, w jaki sposób mogę rozwiązać ten problem ze statycznym inicjalizacją?

Answer 1

Jest to długi strzał, ale ... Jeśli masz inny g++ w twojej PATH niż użyte do budowy bibliotek Boost, pozbyć się go lub przekazać -gxx-name /usr/bin/g++ do icpc. (Kompilator Intel dostosowuje się do wersji GCC, o której myśli, że używasz. -gxx-name pozwala wymusić ten problem.)

OK, prawdopodobnie nie pomogło.

Ubuntu 13.04 nie jest obsługiwany przed Intel Composer XE 2013 SP1, aka. wersja kompilatora 14.0.0. Zobacz "System Requirements" section of the Release Notes i porównaj go z same section for the last 13.x release.

Intel zdecydowanie dąży do zgodności łącza z GCC. Jeśli możesz odtworzyć ten problem w czystej instalacji obsługiwanej wersji systemu Linux, powinieneś być w stanie przesłać zgłoszenie do pomocy technicznej i je naprawić.