Wget ошибка сегментирования

Core was generated by `./helloworld'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  std::operator<< <char, std::char_traits<char>, std::allocator<char> > (__str=<error reading variable: Cannot access memory at address 0x1100>, __os=...)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/bits/basic_string.h:5330
5330          return __ostream_insert(__os, __str.data(), __str.size());
[Current thread is 1 (LWP 1526)]
(gdb) bt
#0  std::operator<< <char, std::char_traits<char>, std::allocator<char> > (__str=<error reading variable: Cannot access memory at address 0x1100>, __os=...)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/bits/basic_string.h:5330
#1  crow::logger::operator<< <std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (
    value=<error reading variable: Cannot access memory at address 0x1100>, this=0x76f95584)
    at /crow-0.1/include/crow/logging.h:88
#2  crow::Connection<crow::SocketAdaptor, crow::Crow<>>::complete_request() (this=0x0)
    at /crow-0.1/include/crow/http_connection.h:338
#3  0x0002ac10 in std::function<void ()>::operator()() const (this=0x20f958)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:2136
#4  crow::response::end (this=0x20f8e8) at /crow-0.1/include/crow/http_response.h:108
#5  crow::TaggedRule<>::<lambda(const crow::request&, crow::response&)>::operator() (__closure=<optimized out>, res=...)
    at /crow-0.1/include/crow/routing.h:475
#6  std::_Function_handler<void(const crow::request&, crow::response&), crow::TaggedRule<Args>::operator()(Func&&) [with Func = main()::<lambda()>; Args = {}; typename std::enable_if<crow::black_magic::CallHelper<Func, crow::black_magic::S<Args ...> >::value, void>::type = void]::<lambda(const crow::request&, crow::response&)> >::_M_invoke(const std::_Any_data &, const crow::request &, crow::response &) (__functor=..., __args#0=..., __args#1=...)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:1740
#7  0x0003e500 in crow::Router::handle (this=0x7ec8dbe4, req=..., res=...)
    at /crow-0.1/include/crow/routing.h:1049
#8  0x00046d60 in crow::Crow<>::handle(crow::request const&, crow::response&) (res=..., req=..., this=<optimized out>)
    at /crow-0.1/include/crow/app.h:53
#9  crow::Connection<crow::SocketAdaptor, crow::Crow<>>::handle() (this=0x20e758)
    at /crow-0.1/include/crow/http_connection.h:321
#10 0x00047644 in crow::HTTPParser<crow::Connection<crow::SocketAdaptor, crow::Crow<>> >::process_message() (this=0x20f770)
    at /crow-0.1/include/crow/parser.h:137
#11 crow::HTTPParser<crow::Connection<crow::SocketAdaptor, crow::Crow<>> >::on_message_complete(http_parser*) (self_=<optimized out>)
    at /crow-0.1/include/crow/parser.h:86
#12 0x0002f68c in http_parser_execute (parser=0x20f770,
    settings=settings@entry=0x4ac64 <crow::HTTPParser<crow::Connection<crow::SocketAdaptor, crow::Crow<>> >::feed(char const*, int)::settings_>,
    data=<optimized out>, len=len@entry=76) at /crow-0.1/include/crow/http_parser_merged.h:2081
#13 0x00043748 in crow::HTTPParser<crow::Connection<crow::SocketAdaptor, crow::Crow<>> >::feed(char const*, int) (length=<optimized out>, buffer=<optimized out>,
    this=<optimized out>) at /crow-0.1/include/crow/parser.h:109
#14 crow::Connection<crow::SocketAdaptor, crow::Crow<>>::do_read()::{lambda(boost::system::error_code const&, unsigned int)#1}::operator()(boost::system::error_code const&, unsigned int) const (bytes_transferred=<optimized out>, ec=..., __closure=0x76f961fc)
    at /crow-0.1/include/crow/http_connection.h:470
#15 boost::asio::detail::binder2<crow::Connection<crow::SocketAdaptor, crow::Crow<>>::do_read()::{lambda(boost::system::error_code const&, unsigned int)#1}, boost::system::error_code, unsigned int>::operator()() (this=0x76f961fc)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/bind_handler.hpp:127
#16 boost::asio::asio_handler_invoke<boost::asio::detail::binder2<crow::Connection<crow::SocketAdaptor, crow::Crow<>>::do_read()::{lambda(boost::system::error_code const&, unsigned int)#1}, boost::system::error_code, unsigned int> >(boost::asio::detail::binder2<crow::Connection<crow::SocketAdaptor, crow::Crow<>>::do_read()::{lambda(boost::system::error_code const&, unsigned int)#1}, boost::system::error_code, unsigned int>&, ...) (function=...)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/handler_invoke_hook.hpp:69
#17 boost_asio_handler_invoke_helpers::invoke<boost::asio::detail::binder2<crow::Connection<crow::SocketAdaptor, crow::Crow<>>::do_read()::{lambda(boost::system::error_code const&, unsigned int)#1}, boost::system::error_code, unsigned int>, {lambda(boost::system::error_code const&, unsigned int)#1}>(boost::asio::detail::binder2<crow::Connection<crow::SocketAdaptor, crow::Crow<>>::do_read()::{lambda(boost::system::error_code const&, unsigned int)#1}, boost::system::error_code, unsigned int>&, {lambda(boost::system::error_code const&, unsigned int)#1}&) (context=..., function=...)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/handler_invoke_helpers.hpp:37
#18 boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, crow::Connection<crow::SocketAdaptor, crow::Crow<>>::do_read()::{lambda(boost::sys---Type <return> to continue, or q <return> to quit---
tem::error_code const&, unsigned int)#1}>::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int) (owner=0x20e540,
    owner@entry=0x36950 <boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int)+376>, base=base@entry=0x20fa00)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/reactive_socket_recv_op.hpp:110
#19 0x00036950 in boost::asio::detail::task_io_service_operation::complete (bytes_transferred=0, ec=..., owner=..., this=<optimized out>)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/task_io_service_operation.hpp:38
#20 boost::asio::detail::epoll_reactor::descriptor_state::do_complete (
    owner=0x36950 <boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned int)+376>, owner@entry=0x20e540, base=base@entry=0x75c00470, ec=..., bytes_transferred=1)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/impl/epoll_reactor.ipp:651
#21 0x000403f4 in boost::asio::detail::task_io_service_operation::complete (bytes_transferred=<optimized out>, ec=..., owner=..., this=0x75c00470)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/task_io_service_operation.hpp:38
#22 boost::asio::detail::task_io_service::do_run_one (ec=..., this_thread=..., lock=..., this=0x20e540)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/impl/task_io_service.ipp:372
#23 boost::asio::detail::task_io_service::run (ec=..., this=0x20e540)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/detail/impl/task_io_service.ipp:149
#24 boost::asio::io_service::run (this=<optimized out>)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/boost/asio/impl/io_service.ipp:59
#25 crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1}::operator()() const (__closure=0x76f9638c)
    at /crow-0.1/include/crow/http_server.h:128
#26 0x0004094c in std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>::_M_invoke<>(std::_Index_tuple<>) (
    this=<optimized out>) at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:1400
#27 std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>::operator()() (this=<optimized out>)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:1389
#28 std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>, void>::operator()() const (this=0x76f96e14)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/future:1347
#29 std::_Function_handler<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> (), std::__future_base::_Task_setter<std::unique_ptr<std::__future_base::_Result<void>, std::__future_base::_Result_base::_Deleter>, std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>, void> >::_M_invoke(std::_Any_data const&) (__functor=...)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:1726
#30 0x0002c70c in std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>::operator()() const (
    this=<optimized out>) at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:2136
#31 std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) (this=0x20e634, __f=<optimized out>, __did_set=0x76f96e13)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/future:532
#32 0x4173f17c in __pthread_once_slow (once_control=0x20e644, init_routine=0x29df0 <__once_proxy@plt>) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_once.c:116
#33 0x000378e4 in __gthread_once (__func=<optimized out>, __once=0x20e644)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/arm-openbmc-linux-gnueabi/bits/gthr-default.h:699
#34 std::call_once<void (std::__future_base::_State_baseV2::*)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*>(std::once_flag&, void (std::__future_base::_State_baseV2::*&&)(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*), std::__future_base::_State_baseV2*&&, std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*&&, bool*&&) (__f=<optimized out>, __once=...)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/mutex:619
#35 std::__future_base::_State_baseV2::_M_set_result(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()---Type <return> to continue, or q <return> to quit---
>, bool) (__ignore_failure=false, __res=..., this=0x20e634) at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/future:392
#36 std::__future_base::_Async_state_impl<std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>, void>::_Async_state_impl(crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} (&&)())::{lambda()#1}::operator()() const (__closure=0x20e67c)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/future:1663
#37 std::_Bind_simple<std::__future_base::_Async_state_impl<std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>, void>::_Async_state_impl(crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} (&&)())::{lambda()#1} ()>::_M_invoke<>(std::_Index_tuple<>) (this=0x20e67c)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:1400
#38 std::_Bind_simple<std::__future_base::_Async_state_impl<std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>, void>::_Async_state_impl(crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} (&&)())::{lambda()#1} ()>::operator()() (this=0x20e67c)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/functional:1389
#39 std::thread::_State_impl<std::_Bind_simple<std::__future_base::_Async_state_impl<std::_Bind_simple<crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} ()>, void>::_Async_state_impl(crow::Server<crow::Crow<>, crow::SocketAdaptor>::run()::{lambda()#1} (&&)())::{lambda()#1} ()> >::_M_run() (this=0x20e678)
    at /sysroots/armv6-openbmc-linux-gnueabi/usr/include/c++/6.2.0/thread:196
#40 0x41a201a0 in std::execute_native_thread_routine (__p=0x20e678)
    at ../../../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libstdc++-v3/src/c++11/thread.cc:83
#41 0x41736154 in start_thread (arg=0x76f97450) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:458
#42 0x416b2260 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:86 from /sysroots/armv6-openbmc-linux-gnueabi/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

@netromdk Here is the backtrace for ref.
Thanks!

Не всегда программы в Linux запускаются как положено. Иногда, в силу разных причин программа вместо нормальной работы выдает ошибку. Но нам не нужна ошибка, нам нужна программа, вернее, та функция, которую она должна выполнять. Сегодня мы поговорим об одной из самых серьезных и непонятных ошибок. Это ошибка сегментации Ubuntu. Если такая ошибка происходит только один раз, то на нее можно не обращать внимания, но если это регулярное явление нужно что-то делать.

Конечно, случается эта проблема не только в Ubuntu, а во всех Linux дистрибутивах, поэтому наша инструкция будет актуальна для них тоже. Но сосредоточимся мы в основном на Ubuntu. Рассмотрим что такое ошибка сегментирования linux, почему она возникает, а также как с этим бороться и что делать.

Что такое ошибка сегментации?

Ошибка сегментации, Segmentation fault, или Segfault, или SIGSEGV в Ubuntu и других Unix подобных дистрибутивах, означает ошибку работы с памятью. Когда вы получаете эту ошибку, это значит, что срабатывает системный механизм защиты памяти, потому что программа попыталась получить доступ или записать данные в ту часть памяти, к которой у нее нет прав обращаться.

Чтобы понять почему так происходит, давайте рассмотрим как устроена работа с памятью в Linux, я попытаюсь все упростить, но приблизительно так оно и работает.

Допустим, в вашей системе есть 6 Гигабайт оперативной памяти, каждой программе нужно выделить определенную область, куда будет записана она сама, ее данные и новые данные, которые она будет создавать. Чтобы дать возможность каждой из запущенных программ использовать все шесть гигабайт памяти был придуман механизм виртуального адресного пространства. Создается виртуальное пространство очень большого размера, а из него уже выделяется по 6 Гб для каждой программы. Если интересно, это адресное пространство можно найти в файле /proc/kcore, только не вздумайте никуда его копировать.

Выделенное адресное пространство для программы называется сегментом. Как только программа попытается записать или прочитать данные не из своего сегмента, ядро отправит ей сигнал SIGSEGV и программа завершится с нашей ошибкой. Более того, каждый сегмент поделен на секции, в некоторые из них запись невозможна, другие нельзя выполнять, если программа и тут попытается сделать что-то запрещенное, мы опять получим ошибку сегментации Ubuntu.

Почему возникает ошибка сегментации?

И зачем бы это порядочной программе лезть, куда ей не положено? Да в принципе, незачем. Это происходит из-за ошибки при написании программ или несовместимых версиях библиотек и ПО. Часто эта ошибка встречается в программах на Си или C++. В этом языке программисты могут вручную работать с памятью, а язык со своей стороны не контролирует, чтобы они это делали правильно, поэтому одно неверное обращение к памяти может обрушить программу.

Почему может возникать эта ошибка при несовместимости библиотек? По той же причине — неверному обращению к памяти. Представим, что у нас есть библиотека linux (набор функций), в которой есть функция, которая выполняет определенную задачу. Для работы нашей функции нужны данные, поэтому при вызове ей нужно передать строку. Наша старая версия библиотеки ожидает, что длина строки будет до 256 символов. Но программа была обновлена формат записи поменялся, и теперь она передает библиотеке строку размером 512 символов. Если обновить программу, но оставить старую версию библиотеки, то при передаче такой строки 256 символов запишутся нормально в подготовленное место, а вот вторые 256 перезапишут данные программы, и возможно, попытаются выйти за пределы сегмента, тогда и будет ошибка сегментирования linux.

Что делать если возникла ошибка сегментирования?

Если вы думаете, что это ошибка в программе, то вам остается только отправить отчет об ошибке разработчикам. Но вы все-таки еще можете попытаться что-то сделать.

Например, если падает с ошибкой сегментации неизвестная программа, то мы можем решить что это вина разработчиков, но если с такой ошибкой падает chrome или firefox при запуске возникает вопрос, может мы делаем что-то не так? Ведь это уже хорошо протестированные программы.

Первое, что нужно сделать — это обновить систему до самой последней версии, возможно, был баг и его уже исправили, а может у вас установлены старые версии библиотек и обновление решит проблему. В Ubuntu это делается так:

sudo apt update
sudo apt full-upgrade

Если это не помогло, нужно обнулить настройки программы до значений по умолчанию, возможно, удалить кэш. Настройки программ в Linux обычно содержатся в домашней папке, скрытых подкаталогах с именем программы. Также, настройки и кэш могут содержаться в каталогах ~/.config и ~/.cache. Просто удалите папки программы и попробуйте снова ее запустить. Если и это не помогло, вы можете попробовать полностью удалить программу, а потом снова ее установить, возможно, какие-нибудь зависимости были повреждены:

sudo apt remove пакет_программы
sudo apt autoremove
sudo apt install пакет_программы

Если есть возможность, попробуйте установить программу из другого источника, например, не из PPA, а более старую версию, из официальных репозиториев.

Когда вы все это выполнили, скорее всего, проблема не в вашем дистрибутиве, а в самой программе. Нужно отправлять отчет разработчикам. В Ubuntu это можно сделать с помощью программы apport-bug. Обычно Ubuntu предлагает это сделать сразу, после того как программа завершилась с ошибкой сегментирования. Если же ошибка сегментирования Ubuntu встречается не в системной программе, то вам придется самим искать разработчиков и вручную описывать что произошло.

Чтобы помочь разработчикам решить проблему, недостаточно отправить им только сообщение что вы поймали Segmentation Fault, нужно подробно описать проблему, действия, которые вы выполняли перед этим, так чтобы разработчик мог их воспроизвести. Также, желательно прикрепить к отчету последние функции, которые вызывала программа (стек вызовов функций), это может очень сильно помочь разработчикам.

Рассмотрим, как его получить. Это не так уж сложно. Сначала запустите вашу программу, затем узнайте ее PID с помощью команды:

pgrep программа

Дальше запускаем отладчик gdb:

sudo gdb -q

Подключаемся к программе:

(gdb) attach ваш_pid

После подключения программа станет на паузу, продолжаем ее выполнение командой:

(gdb) continue

Затем вам осталось только вызвать ошибку:

И набрать команду, которая выведет стек последних вызовов:

(gdb) backtrace

Вывод этой команды и нужно отправлять разработчикам. Чтобы отключиться от программы и выйти наберите:

(gdb) detach
(gdb) quit

Дальше остается отправить отчет и ждать исправления ошибки. Если вы не уверены, что ошибка в программе, можете поспрашивать на форумах. Когда у вас есть стек вызовов, уже можно попытаться, если не понять в чем проблема, то попытаться узнать, не сталкивался ли с подобной проблемой еще кто-то.

Выводы

Теперь у вас есть приблизительный план действий, что нужно делать, когда появляется ошибка сегментирования сделан дамп памяти ubuntu. Если вы знаете другие способы решить эту проблему, напишите в комментариях!

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Segmentation Fault means the program, in this case, wget, tried to access an invalid memory address and therefore was terminated by the kernel. This typically happen due to a program bug, so while it is quite likely it is being triggered by a specific website or web page (considering you seem to be able to reproduce it quite consistently, on multiple platforms, at the same point), it is still likely you have exposed a bug in wget itself.

In order to find where in wget the segmentation fault is happening, you can use the gdb program (GNU debugger) to get a stack trace of wget at the time it crashed, which is possible since you have a core file. (A core dump is a copy of the image of the running program at the time it was terminated due to an invalid operation such as a Segmentation Fault.)

In order to do so, use the following command:

$ gdb wget core

Which will start the debugger on the wget binary (from the path) and restore the core file (in the current directory) as the image of the running program.

gdb will then print some information about the program and give you a prompt:

$ gdb wget core
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
...
Core was generated by `wget --directory-prefix=... --recursive --page-requisites --span-hosts --tries=... --timeout=... --reject=*.tar --convert-links --adjust-extension --continue --no-check-certificate http://website.com/'.
Program terminated with signal SIGSEGV, Segmentation Fault.
(gdb) _

At that point, you can use the command bt (short for «backtrace») to show you what was being executed at the time the program crashed. Which is usually a good place to start looking for the bug.

For instance, you might see something like this:

(gdb) bt
#0  0x00007f5371206363 in __select_nocancel () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000559e5acbf21c in select_fd ()
#2  0x0000559e5acf0bde in wgnutls_poll ()
#3  0x0000559e5acbf3a2 in poll_internal ()
#4  0x0000559e5acbf6ed in fd_peek ()
#5  0x0000559e5ace423d in fd_read_hunk ()
#6  0x0000559e5acd5ef9 in gethttp ()
#7  0x0000559e5acd9b26 in http_loop ()
#8  0x0000559e5ace53c8 in retrieve_url ()
#9  0x0000559e5ace273b in retrieve_tree ()
#10 0x0000559e5acbe67d in main ()

You can then quit gdb with the q (for «quit») command:

(gdb) q

It’s usually helpful if you have the «debug symbols» installed. These are the information generated by the compiler for debugging binaries, which is usually stripped for binaries that are installed on a system, so they’re smaller in size. That information can be saved to an alternate location (typically under /usr/lib/debug) that can be located by gdb while trying to debug a binary.

With that information present, your backtraces will typically have more information attached to them, such as the name of all internal functions.

On Debian, you can install the debug info for wget with the following command:

$ sudo apt-get install wget-dbgsym

You might also want to install the debug symbols for glibc:

$ sudo apt-get install libc6-amd64-dbgsym

Having said that, before you start looking at why wget crashed, you might want to try the latest version of wget, which it seems is version 1.9.4 that you can download here. That is a source package, so you might need to build from sources to get it to work in your system.

This is because a segmentation fault is typically caused by a bug, and it’s quite possible this bug was already fixed in wget and the fix is present in the latest version.

In case you get the same problem in the latest version, consider getting a core file and using gdb to get a backtrace, then report the bug to wget maintainers so they have a chance to address it.

In case it’s fixed on latest wget 1.9.4 but it exists in a version of Debian you are using, consider reporting this to Debian, so they can have a chance to backport the patch to their version of wget.

There’s also a new project called wget2, it looks like they’re trying to replace wget with a new codebase. You might want to check whether that one works or not… It seems recent Debian ship it under the name «wget2».

I hope these pointers are helpful too!

The key here is the line

'/lib/libc.so.5': not in executable format: File truncated

The C library is one of the core components of a Unix-like system, including Linux. That it is corrupted means that virtually nothing will work. You are lucky that your system is limping along, but it’s quite possible that starting or restarting anything will fail.

DO NOT REBOOT THE SYSTEM. In its current state, it almost certainly won’t come back up.

Especially because this is a VPS, and because this happened together with an upgrade, I’m wondering if maybe you ran out of resources like disk space or inodes. I wouldn’t put it beyond something like this to have broken more things on your system, so you may need to implement some form of disaster recovery. The easiest option might very well be to restore your most recent backup.

At the very least, you will have to reinstall the C library. On my Debian system, this is provided by the libc6 family of packages, primarily libc6. You can run dpkg -S libc.so to list all packages that provide files with names containing the substring libc.so. If you can’t run this on the VPS in question, set up a separate system (could be a low-provisioned VM somewhere; that doesn’t really matter much) with the same release of Debian, update the package lists, and run the command there; it will tell you which packages are candidates for reinstallation.

Once you have the very basics back to working, you may want to check out How to verify that package-installed files match originals? for how to verify that (at least mostly) nothing else has been corrupted as well.

Personally, especially since presumably this is an important system (since you state it is a «production server with live traffic»), I’d probably prefer just initiating whatever disaster recovery plans you have in place. Chances are that it will be easier and quicker than trying to repair things in-place and never quite knowing what errors you might possibly have missed. This is really just a variation of needing to nuke from orbit to be sure.