2017-01-27 3 views
0

Я запускаю Redhawk 2.0.4 на CentOS 7.3.1611. Я скомпилировал и установил Vita49Libraries (3.0.0), SourceVita49 (3.0.1) и SinkVita49 (3.0.1) из источника. Когда я перетаскиваю компонент SourceVita49 или SinkVita49 в песочницу в IDE, я получаю следующие ошибки:Redhawk Vita49 Ошибка сегментации с CentOS7

Ошибка при ожидании запуска компонента SinkVITA49_1. Компонент завершен в ожидании запуска. SinkVITA49_1 Заключен с кодом выхода SIGSEGV (11)

Ошибка при ожидании запуска компонента SourceVITA49_1. Компонент завершен в ожидании запуска. SourceVITA49_1 Отменено с кодом выхода SIGSEGV (11)

Глядя на GitHub here я вижу вопрос о "катастрофе" из Vita49Libraries под Fedora24.

Можете ли вы подтвердить, что эта проблема на Fedora24 - это те же ошибки сегментации, которые я вижу?

Кто-нибудь знает, как получить компоненты VITA49 для работы под CentOS7?

ответ

0

Это, похоже, та же проблема, о которой сообщается в ссылке github. Вы можете повторить следующие шаги по грузчиком:

# Run the redhawk 2.0.4 container for el7 with escalated privileges so we can get a core dump and trace it 
[[email protected] ~] docker run -it --rm --privileged --cap-add CAP_PTRACE axios/redhawk:2.0-el7 

# Clone and build 
[[email protected]] git clone https://github.com/RedhawkSDR/VITA49Libraries.git 
[[email protected]] pushd VITA49Libraries/cpp/ 
[[email protected]] ./reconf && ./configure && make -j && sudo make install && popd 

[[email protected]] git clone https://github.com/RedhawkSDR/SinkVITA49.git 
[[email protected]] pushd SinkVITA49/cpp/ 
[[email protected]] ./reconf && ./configure && make -j && sudo make install && popd 

# Set core dump size to unlimited. 
[[email protected]] ulimit -c unlimited 

# Hop into python and launch component 
[[email protected]] python 
>>> from ossie.utils import sb 
>>> snk = sb.launch('rh.SinkVITA49') 

# It will crash 
[[email protected] ~]$ ls 
core.4287 SinkVITA49 VITA49Libraries 

# Install gdb and trace out the issue 
[[email protected] ~]$ sudo yum install gdb 
[[email protected] ~]$ gdb /var/redhawk/sdr/dom/components/rh/SinkVITA49/cpp/SinkVITA49 core.4287 

# leads us to 

... 
#1 0x00007f254971204e in std::string::assign(std::string const&)() from /lib64/libstdc++.so.6 
#2 0x00007f254c802055 in operator= (__str="", this=0x7f254ca396f0 <_leapSecondsFile>) at /usr/include/c++/4.8.2/bits/basic_string.h:547 
#3 _init() at vrt_src/cpp_src/vrt/lib/VRTConfig.cc:84 
#4 0x00007f254c802f25 in vrt::VRTConfig::getLeapSecondsFile() at vrt_src/cpp_src/vrt/lib/VRTConfig.cc:141 
#5 0x00007f254c7ae0b5 in vrt::LeapSeconds::getDefaultInstance() at vrt_src/cpp_src/vrt/lib/LeapSeconds.cc:195 
#6 0x00007f254c7fad3d in vrt::TimeStamp::TimeStamp (this=0x7f254ca39640 <vrt::TimeStamp::NO_TIME_STAMP>, tsiMode=<optimized out>, tsfMode=vrt::FractionalMode_None, tsi=<optimized out>, tsf=9223372036854775808, sr=nan(0x8000000000000)) 
    at vrt_src/cpp_src/vrt/lib/TimeStamp.cc:84 
#7 0x00007f254c781d35 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at vrt_src/cpp_src/vrt/lib/TimeStamp.cc:28 
... 

# Which is the static initialization within the TimeStamp file. 

В то время как я не пробовал, я полагаю, выполнив те же действия с контейнером el6 «Докер запустить -это --rm --privileged --cap- добавить CAP_PTRACE axios/redhawk: 2.0 "не будет основной дамп.

+0

См. Https://isocpp.org/wiki/faq/ctors#static-init-order, _leapSecondsFile - это std :: string, которая очень сложна при статической инициализации. У CentOS 7, вероятно, есть новый компилятор, который просто генерирует несколько разных порядков инициализации. –

+0

Спасибо, что воспроизвели это на вашей стороне. Сейчас я останусь с CentOS 6. –