к вопросу. Пожалуйста, посмотрите это!
Есть конечно
#include <iostream>
#include <vector>
#include <memory>
int main()
{
std::cout << "Hello World" << std::endl;
std::vector<std::shared_ptr<int>> y {};
std::cout << "Hello World" << std::endl;
}
абсолютно ничего плохого в самой программе. Основная причина segfault зависит от среды, в которой он построен и работает.Фон
В Amazon мы используем систему сборки, которая собирает и развертывает двоичные файлы ( а такжеlib) вbinпочти машина независимым образом. Для нашего случая это в основном означает, что он развертывает исполняемый файл (созданный из вышеуказанной программы) в а также$project_dir/build/bin/почти все его зависимости (т.е. общие библиотеки) в, Почему я использовал фразу$project_dir/build/lib/"почти" потому что для общих библиотек таких и, возможно, несколько других, исполняемый файл выбирает из системы (то есть изlibc.so, libm.so, ld-linux-x86-64.so.2 ). Обратите внимание, что это/lib64предполагаемый подобрать изlibstdc++ хотя.$project_dir/build/libТеперь я запускаю его следующим образом:
Однако, если я запустил его, не устанавливая
$ LD_LIBRARY_PATH=$project_dir/build/lib ./build/bin/run
segmentation fault
, Работает нормально.LD_LIBRARY_PATHдиагностика
информация для обоих случаев (обратите внимание, что я отредактировал вывод, чтобы упомянутьlddполный версия библиотекивезде, где есть разницаи без LD_LIBRARY_PATH:)
$ LD_LIBRARY_PATH=$project_dir/build/lib ldd ./build/bin/run
linux-vdso.so.1 => (0x00007ffce19ca000)
libstdc++.so.6 => $project_dir/build/lib/libstdc++.so.6.0.20
libgcc_s.so.1 => $project_dir/build/lib/libgcc_s.so.1
libc.so.6 => /lib64/libc.so.6
libm.so.6 => /lib64/libm.so.6
/lib64/ld-linux-x86-64.so.2 (0x0000562ec51bc000)
2. GDB, когда это segfaults
$ ldd ./build/bin/run
linux-vdso.so.1 => (0x00007fffcedde000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6.0.16
libgcc_s.so.1 => /lib64/libgcc_s-4.4.6-20110824.so.1
libc.so.6 => /lib64/libc.so.6
libm.so.6 => /lib64/libm.so.6
/lib64/ld-linux-x86-64.so.2 (0x0000560caff38000)
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7dea45c in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.209.62.al12.x86_64
(gdb) bt
#0 0x00007ffff7dea45c in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#1 0x00007ffff7df0c55 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
#2 0x00007ffff7b1dc41 in std::locale::_S_initialize() () from $project_dir/build/lib/libstdc++.so.6
#3 0x00007ffff7b1dc85 in std::locale::locale() () from $project_dir/build/lib/libstdc++.so.6
#4 0x00007ffff7b1a574 in std::ios_base::Init::Init() () from $project_dir/build/lib/libstdc++.so.6
#5 0x0000000000400fde in _GLOBAL__sub_I_main () at $project_dir/build/gcc-4.9.4/include/c++/4.9.4/iostream:74
#6 0x00000000004012ed in __libc_csu_init ()
#7 0x00007ffff7518cb0 in __libc_start_main () from /lib64/libc.so.6
#8 0x0000000000401021 in _start ()
(gdb)
для случая сегфо. Я нашел что-то подозрительное, так как оно ищетLD_DEBUG=all символ, и когда он не может найти это, он дает segfault (это моя интерпретация следующего выходного фрагмента BTW):pthread_onceНо я не вижу никаких
initialize program: $project_dir/build/bin/run
symbol=_ZNSt8ios_base4InitC1Ev; lookup in file=$project_dir/build/bin/run [0]
symbol=_ZNSt8ios_base4InitC1Ev; lookup in file=$project_dir/build/lib/libstdc++.so.6 [0]
binding file $project_dir/build/bin/run [0] to $project_dir/build/lib/libstdc++.so.6 [0]: normal symbol `_ZNSt8ios_base4InitC1Ev' [GLIBCXX_3.4]
symbol=_ZNSt6localeC1Ev; lookup in file=$project_dir/build/bin/run [0]
symbol=_ZNSt6localeC1Ev; lookup in file=$project_dir/build/lib/libstdc++.so.6 [0]
binding file $project_dir/build/lib/libstdc++.so.6 [0] to $project_dir/build/lib/libstdc++.so.6 [0]: normal symbol `_ZNSt6localeC1Ev' [GLIBCXX_3.4]
symbol=pthread_once; lookup in file=$project_dir/build/bin/run [0]
symbol=pthread_once; lookup in file=$project_dir/build/lib/libstdc++.so.6 [0]
symbol=pthread_once; lookup in file=$project_dir/build/lib/libgcc_s.so.1 [0]
symbol=pthread_once; lookup in file=/lib64/libc.so.6 [0]
symbol=pthread_once; lookup in file=/lib64/libm.so.6 [0]
symbol=pthread_once; lookup in file=/lib64/ld-linux-x86-64.so.2 [0]
для случая, когда он работает успешно!pthread_onceВопросов
Компилятор и платформа
я используюGCC 4.9 на RHEL5.Эксперименты
E # 1Если я прокомментирую следующую строку:Он компилируется и работает нормально!
std::vector<std::shared_ptr<int>> y {};
E # 2
Я просто включил следующий заголовок в мою программу:и связаны соответственно. Теперь это работает без каких-либо ошибок. Таким образом, кажется, имея зависимость от
#include <boost/filesystem.hpp>
Некоторые требования выполнены или проблема обойдена!libboost_system.so.1.53.0.E # 3
Я сделал следующие шаги шаг за шагом.libboost_system.so.1.53.0Вместо того, чтобы использовать
в самом коде я использую оригинальный код и запускаю его предзагрузкой#include <boost/filesystem.hpp> с помощьюlibboost_system.so следующее:LD_PRELOADи все прошло успешно!
$ LD_PRELOAD=$project_dir/build/lib/libboost_system.so $project_dir/build/bin/run
Затем я сделал
наldd который дал список библиотек, две из которых были:libboost_system.soТак что вместо предварительной загрузки
/lib64/librt.so.1
/lib64/libpthread.so.0
Я предварительно загружаюlibboost_system а такжеlibrt отдельно:libpthreadВ обоих случаях все прошло успешно.
$ LD_PRELOAD=/lib64/librt.so.1 $project_dir/build/bin/run
$ LD_PRELOAD=/lib64/libpthread.so.0 $project_dir/build/bin/run
Теперь мой вывод заключается в том, что при загрузке либо
или жеlibrt (или жеlibpthreadобе ), некоторые требования выполнены или проблема обойдена! Тем не менее, я до сих пор не знаю причину проблемы.Параметры компиляции и компоновки
используя CMake-lpthread команда, то это сработало, как мы уже видели, чтоsetподжимать оно работает! libpthreadДля того, чтобы увидеть
строить разница между этими двумя случаями (когда-он-работа а такжекогда-то-дает-Segfault), Я построил это вподробный режим мимоходом в GCC, чтобы увидеть этапы компиляции и параметры, которые он фактически передает-v (компилятор) иcc1plus (Линкер).collect2Обратите внимание, что пути были отредактированы для краткости, используя знаки доллара и фиктивные пути.
($ / gcc-4.9.4 / cc1plus -quiet -v -I / a / include -I / b / include -iprefix $ / gcc-4.9.4 / -MMD main.cpp.d -MF main.cpp.od - MT main.cpp.o -D_GNU_SOURCE -D_REENTRANT -D __USE_XOPEN2K8 -D _LARGEFILE_SOURCE -D _FILE_OFFSET_BITS = 64 -D __STDC_FORMAT_MACROS -D __STDC -LIMIT_MACthgmp.mpm-smps_mps_p_DD_SD_MSDSMPS_DF_SDKS_SD_RUS_DB_SD_S_SD_D_S_D_S_S_D_S_S_D_S_S_S_D_S_S_MD_S_D_S_S_S_D_S_S_WD_S_S_DF_S_S_D_D_S $_DF_D_S_D_S $_D_S_D_S $_DF -march = core2 -auxbase-strip main.cpp.o -g -O3 -Wall -Wextra -std = gnu ++ 1y -version -fdiagnostics-color = auto -ftemplate-deep = 128 -fno-operator-names -o -o /tmp/ccxfkRyd.s)
Независимо от того, работает он или нет, аргументы командной строки
точно так же. Нет разницы вообще. Это не кажется очень полезным.cc1plusРазница, однако, заключается во времени соединения. Вот что я вижу,
для случая, когда это работает$ / gcc-4.9.4 / collect2 -plugin $ / gcc-4.9.4 / liblto_plugin.so:
-plugin-opt = $ / gcc-4.9.4 / lto-wrapper -plugin-opt = -fresolution = / tmp / cchl8RtI.res -plugin-opt = -pass-through = -lgcc_s -plugin-opt = -pass- through = -lgcc -plugin-opt = -pass-through = -lpthread -plugin-opt = -pass-through = -lc -plugin-opt = -pass-through = -lgcc_s -plugin-opt = -pass-through = -lgcc --eh-frame-hdr -m elf_x86_64 -export-dynamic -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o запустить /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o $ / gcc-4.9.4 / crtbegin.o -L / a / lib -L / b / lib -L / c / lib
-lpthread --as необходимый main.cpp.o -lboost_timer -lboost_wave -lboost_chrono -lboost_filesystem -lboost_graph -lboost_locale -lboost_thread -lboost_wserialization -lboost_atomic -lboost_context -lboost_date_time -lboost_iostreams -lboost_math_c99 -lboost_math_c99f -lboost_math_c99l -lboost_math_tr1 -lboost_math_tr1f -lboost_math_tr1l -lboost_mpi -lboost_prg_exec_monitor -lboost_program_options -lboost_random -lboost_regex -lboost_serialization -lboost_signals -lboost_system -lboost_unit_test_framework -lboost_exception -lboost_test_exe_exe -exe / lgcc_s -lgcc-lpthread -lc -lgcc_s -lgcc $ / gcc-4.9.4 / crtend.o /usr/lib/../lib64/crtn.oКак вы видете,
упомянуто-lpthreadдважды! Первый (за которым следует-lpthread) является--as-neededотсутствуетдля случая, когда он дает Segfault , Этотолько Разница между этими двумя случаями.Выход из
nm -CИнтересно, что выход в обоих случаях одинаково (nm -Cесли вы игнорируете целочисленные значения в первых столбцах).С точки зрения C ++ это выглядит как UB из-за нарушения ODR. Символы стандартной библиотеки, которая использовалась во время компиляции, должны совпадать с символами во время компоновки, что иногда здесь не так. Просто перекомпиляция на целевой машине должна исправить это. Если вы не можете этого сделать, проверьте, какие версии библиотеки совместимы с двоичными файлами, и убедитесь, что на целевой машине установлена и используется такая версия. В качестве альтернативы вы можете попытаться статически связать некоторые библиотеки вместо использования динамического связывания, но вы, вероятно, не можете сделать это для всего.
0000000000402580 d _DYNAMIC
0000000000402798 d _GLOBAL_OFFSET_TABLE_
0000000000401000 t _GLOBAL__sub_I_main
0000000000401358 R _IO_stdin_used
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
U _Unwind_Resume
0000000000401150 W std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_destroy()
0000000000401170 W std::vector<std::shared_ptr<int>, std::allocator<std::shared_ptr<int> > >::~vector()
0000000000401170 W std::vector<std::shared_ptr<int>, std::allocator<std::shared_ptr<int> > >::~vector()
0000000000401250 W std::vector<std::unique_ptr<int, std::default_delete<int> >, std::allocator<std::unique_ptr<int, std::default_delete<int> > > >::~vector()
0000000000401250 W std::vector<std::unique_ptr<int, std::default_delete<int> >, std::allocator<std::unique_ptr<int, std::default_delete<int> > > >::~vector()
U std::ios_base::Init::Init()
U std::ios_base::Init::~Init()
0000000000402880 B std::cout
U std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)
0000000000402841 b std::__ioinit
U std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
U operator delete(void*)
U operator new(unsigned long)
0000000000401510 r __FRAME_END__
0000000000402818 d __JCR_END__
0000000000402818 d __JCR_LIST__
0000000000402820 d __TMC_END__
0000000000402820 d __TMC_LIST__
0000000000402838 A __bss_start
U __cxa_atexit
0000000000402808 D __data_start
0000000000401100 t __do_global_dtors_aux
0000000000402820 t __do_global_dtors_aux_fini_array_entry
0000000000402810 d __dso_handle
0000000000402828 t __frame_dummy_init_array_entry
w __gmon_start__
U __gxx_personality_v0
0000000000402838 t __init_array_end
0000000000402828 t __init_array_start
00000000004012b0 T __libc_csu_fini
00000000004012c0 T __libc_csu_init
U __libc_start_main
w __pthread_key_create
0000000000402838 A _edata
0000000000402990 A _end
000000000040134c T _fini
0000000000400e68 T _init
0000000000401028 T _start
0000000000401054 t call_gmon_start
0000000000402840 b completed.6661
0000000000402808 W data_start
0000000000401080 t deregister_tm_clones
0000000000401120 t frame_dummy
0000000000400f40 T main
00000000004010c0 t register_tm_clones