Ошибка сегментирования core dumped centos

0

4

#0  0x080e38f2 in _mm_set_epi32 ()
No symbol table info available.
#1  0xdfffffef in ?? ()
No symbol table info available.
#2  0xddfecb7f in ?? ()
No symbol table info available.
#3  0xbffaffff in ?? ()
No symbol table info available.
#4  0x08098331 in world_horse_initialize () at world_horse.c:318
        land_path = "../../data/horse/personality.csv", '00' <repeats 223 times>
        i = 0
#5  0x08088662 in sv_initialize (max_world_num=100) at sv.c:167
No locals.
#6  0x080a39c6 in main_initialize () at main.c:158
No locals.
#7  0x080e68bc in svbase_initialize ()
No symbol table info available.
#8  0x080a36c7 in main (argc=1, argv=0xbffff754) at main.c:51
No locals.

Stack level 0, frame at 0xbfff29d8:
 eip = 0x80e38f2 in _mm_set_epi32; saved eip 0xdfffffef
 called by frame at 0xbfff29dc
 Arglist at 0xbfff29d0, args: 
 Locals at 0xbfff29d0, Previous frame's sp is 0xbfff29d8
 Saved registers:
  eip at 0xbfff29d4

mm_set_epi32();
  _mm_store_si128((__m128i *)&v34, a1);
  mm_load_si128();
  _mm_store_si128((__m128i *)&v36, a1);
  mm_load_si128();
  _mm_store_si128((__m128i *)&v35, a1);

У меня есть процесс в Linux, в котором возникает ошибка сегментации. Как я могу сообщить ему генерировать дамп ядра при сбое?

Ответ 1

Это зависит от того, какую оболочку вы используете. Если вы используете bash, то команда ulimit управляет несколькими параметрами, относящимися к выполнению программы, например, следует ли сбрасывать ядро. Если вы введете:

ulimit -c unlimited

 то это сообщит bash, что ее программы могут сбрасывать ядра любого размера. Вы можете указать размер, например, 52 M вместо неограниченного, если хотите, но на практике в этом нет необходимости, поскольку размер файлов ядра, вероятно, никогда не будет иметь для вас значения. А вот в tcsh необходимо выполнить:

limit coredumpsize unlimited

 Ответ 2

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

gcore <pid>

 Если же gcore недоступен в вашей системе, тогда:

kill -ABRT <pid>

 Не используйте kill -SEGV, так как это часто приводит к вызову обработчика сигналов, что затрудняет диагностику зависшего процесса.

Ответ 3

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

sysctl kernel.core_pattern

 или:

cat /proc/sys/kernel/core_pattern

 где %e — имя процесса, а %t — системное время. Вы можете изменить его в /etc/sysctl.conf и перезагрузить с помощью sysctl -p. Если файлы ядра не генерируются и далее (проверить это можно с помощью: sleep 10 & и killall -SIGSEGV sleep), проверьте ограничения с помощью команды:

 ulimit -a.

Если размер файла ядра ограничен, выполните:

ulimit -c unlimited

чтобы сделать его неограниченным.

Затем снова проверьте, что дамп ядра выполнен успешно — вы увидите «(core dumped)» после индикации ошибки сегментации, как показано ниже:

Segmentation fault: 11 (core dumped)

В Ubuntu дампы ядра обрабатываются Apport и могут быть расположены в /var/crash/. Однако в стабильных релизах он отключен по умолчанию.

Ответ 4

Возможно, вы можете сделать это следующим образом: программа, показанная ниже, демонстрирует, как отловить ошибку сегментации и передать ее отладчику (это оригинальный код, используемый под AIX), и он также печатает трассировку стека до момента ошибки сегментации. Для системы Linux вам нужно будет изменить переменную sprintf для использования в gdb.

#include <stdio.h>

#include <signal.h>

#include <stdlib.h>

#include <stdarg.h>

 static void signal_handler(int);

static void dumpstack(void);

static void cleanup(void);

void init_signals(void);

void panic(const char *, …);

struct sigaction sigact;

char *progname;

int main(int argc, char **argv) {

    char *s;

    progname = *(argv);

    atexit(cleanup);

    init_signals();

    printf(«About to seg fault by assigning zero to *sn»);

    *s = 0;

    sigemptyset(&sigact.sa_mask);

    return 0;

}

void init_signals(void) {

    sigact.sa_handler = signal_handler;

    sigemptyset(&sigact.sa_mask);

    sigact.sa_flags = 0;

    sigaction(SIGINT, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGSEGV);

    sigaction(SIGSEGV, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGBUS);

    sigaction(SIGBUS, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGQUIT);

    sigaction(SIGQUIT, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGHUP);

    sigaction(SIGHUP, &sigact, (struct sigaction *)NULL);

    sigaddset(&sigact.sa_mask, SIGKILL);

    sigaction(SIGKILL, &sigact, (struct sigaction *)NULL);

}

static void signal_handler(int sig) {

    if (sig == SIGHUP) panic(«FATAL: Program hanged upn»);

    if (sig == SIGSEGV || sig == SIGBUS){

        dumpstack();

        panic(«FATAL: %s Fault. Logged StackTracen», (sig == SIGSEGV) ? «Segmentation» : ((sig == SIGBUS) ? «Bus» : «Unknown»));

    }

    if (sig == SIGQUIT) panic(«QUIT signal ended programn»);

    if (sig == SIGKILL) panic(«KILL signal ended programn»);

    if (sig == SIGINT) ;

}

void panic(const char *fmt, …) {

    char buf[50];

    va_list argptr;

    va_start(argptr, fmt);

    vsprintf(buf, fmt, argptr);

    va_end(argptr);

    fprintf(stderr, buf);

    exit(-1);

}

static void dumpstack(void) {

    /* Эта процедура взята с http://www.whitefang.com/unix/faq_toc.html   

 ** Раздел 6.5. Изменено на перенаправление в файл для предотвращения неопределенного поведения

    */

    /* Это нужно изменить… */

    char dbx[160];

    sprintf(dbx, «echo ‘wherendetach’ | dbx -a %d > %s.dump», getpid(), progname);

    /* Измените dbx на gdb */

    system(dbx);

    return;

}

void cleanup(void) {

    sigemptyset(&sigact.sa_mask);

    /* Выполните здесь любые действия по очистке */

}

 Возможно, вам придется дополнительно добавить некие параметры, чтобы заставить gdb сделать дамп ядра.

Ответ 5

Чтобы активировать дамп ядра, сделайте следующее:

1. В /etc/profile закомментируйте строку:

# ulimit -S -c 0 > /dev/null 2>&1

1. В /etc/security/limits.conf закомментируйте строку: 

* soft core 0

1. Выполните команду limit coredumpsize unlimited и проверьте ее с помощью cmd limit:

# limit coredumpsize unlimited

# limit

cputime           unlimited

filesize            unlimited

datasize           unlimited

stacksize         10240 kbytes

coredumpsize  unlimited

memoryuse     unlimited

vmemoryuse   unlimited

descriptors      1024

memorylocked 32 kbytes

maxproc          528383

1. Для проверки записи файла ядра можно завершить соответствующий процесс командой kill -s SEGV <PID> (необязательно, просто в случае, если файл ядра не записывается, это можно использовать как проверку):

# kill -s SEGV <PID>

1. После записи corefile убедитесь, что настройки coredump снова отключены в соответствующих файлах.

Ответ 6

Стоит упомянуть, что если у вас установлен systemd, то ситуация немного меняется. Обычно файлы ядра передаются через systemd-coredump(8) посредством значения core_pattern sysctl. Размер rlimit файла ядра, как правило, уже настроен как «неограниченный».

Затем можно получить дампы ядра с помощью coredumpctl(1).

Хранение дампов ядра и т. д. настраивается coredump.conf(5). Примеры получения файлов ядра есть на man-странице coredumpctl, но вкратце это выглядит следующим образом:

[vps@phoenix]~$ coredumpctl list test_me | tail -1

Sun 2019-01-20 11:17:33 CET   16163  1224  1224  11 present /home/vps/test_me

 Получите файл ядра:

[vps@phoenix]~$ coredumpctl -o test_me.core dump 16163

Ответ 7

Для Ubuntu

Создайте ~/.config/apport/settings со следующим содержимым:

[main]

unpackaged=true

 (эта команда указывает apport писать дампы ядра для пользовательских приложений).

Выполните: 

ulimit -c. 

Если выдает 0, исправьте это с помощью:

ulimit -c unlimited

 На всякий случай перезапустите apport:

sudo systemctl restart apport

 Файлы дампа теперь записываются в /var/crash/. Но вы не можете использовать их с gdb. Чтобы использовать их в gdb, выполните:

apport-unpack <location_of_report> <target_directory>

 Дополнительная информация:

1. В некоторых ответах предлагается изменить core_pattern. Имейте в виду, что этот файл может быть перезаписан службой apport при перезапуске.

2. Простая остановка apport может не помочь.

3. Значение ulimit -c может измениться автоматически. Обязательно проверяйте его регулярно во время настройки создания дампа ядра.

Ответ 8

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

#include <sys/resource.h>

 bool enable_core_dump(){    

    struct rlimit corelim;

    corelim.rlim_cur = RLIM_INFINITY;

    corelim.rlim_max = RLIM_INFINITY;

    return (0 == setrlimit(RLIMIT_CORE, &corelim));

}

Не всегда программы в 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. Если вы знаете другие способы решить эту проблему, напишите в комментариях!

The core file is normally called core and is located in the current working directory of the process. However, there is a long list of reasons why a core file would not be generated, and it may be located somewhere else entirely, under a different name. See the core.5 man page for details:

DESCRIPTION

The default action of certain signals is to cause a process to
terminate and produce a core dump file, a disk file containing an
image of the process’s memory at the time of termination. This image
can be used in a debugger (e.g., gdb(1)) to inspect the state of the
program at the time that it terminated. A list of the signals which
cause a process to dump core can be found in signal(7).

…

There are various circumstances in which a core dump file is not produced:

   *  The process does not have permission to write the core file.  (By
      default, the core file is called core or core.pid, where pid is
      the ID of the process that dumped core, and is created in the
      current working directory.  See below for details on naming.) 
      Writing the core file will fail if the directory in which it is to
      be created is nonwritable, or if a file with the same name exists
      and is not writable or is not a regular file (e.g., it is a
      directory or a symbolic link).
   *  A (writable, regular) file with the same name as would be used for
      the core dump already exists, but there is more than one hard link
      to that file.
   *  The filesystem where the core dump file would be created is full;
      or has run out of inodes; or is mounted read-only; or the user has
      reached their quota for the filesystem.
   *  The directory in which the core dump file is to be created does
      not exist.
   *  The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size)
      resource limits for the process are set to zero; see getrlimit(2)
      and the documentation of the shell's ulimit command (limit in
      csh(1)).
   *  The binary being executed by the process does not have read
      permission enabled.
   *  The process is executing a set-user-ID (set-group-ID) program that
      is owned by a user (group) other than the real user (group) ID of
      the process, or the process is executing a program that has file
      capabilities (see capabilities(7)).  (However, see the description
      of the prctl(2) PR_SET_DUMPABLE operation, and the description of
      the /proc/sys/fs/suid_dumpable file in proc(5).)
   *  (Since Linux 3.7) The kernel was configured without the
      CONFIG_COREDUMP option.

In addition, a core dump may exclude part of the address space of the
process if the madvise(2) MADV_DONTDUMP flag was employed.

Naming of core dump files

By default, a core dump file is named core, but the
/proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21) can
be set to define a template that is used to name core dump files.
The template can contain % specifiers which are substituted by the
following values when a core file is created:

       %%  a single % character
       %c  core file size soft resource limit of crashing process (since
           Linux 2.6.24)
       %d  dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE
           (since Linux 3.7)
       %e  executable filename (without path prefix)
       %E  pathname of executable, with slashes ('/') replaced by
           exclamation marks ('!') (since Linux 3.0).
       %g  (numeric) real GID of dumped process
       %h  hostname (same as nodename returned by uname(2))
       %i  TID of thread that triggered core dump, as seen in the PID
           namespace in which the thread resides (since Linux 3.18)
       %I  TID of thread that triggered core dump, as seen in the
           initial PID namespace (since Linux 3.18)
       %p  PID of dumped process, as seen in the PID namespace in which
           the process resides
       %P  PID of dumped process, as seen in the initial PID namespace
           (since Linux 3.12)
       %s  number of signal causing dump
       %t  time of dump, expressed as seconds since the Epoch,
           1970-01-01 00:00:00 +0000 (UTC)
       %u  (numeric) real UID of dumped process

I have been fighting this problem for quite a long but could not get a solution. Had searched net but could not find anything concrete.

I have removed all openJDK1.8.0_xx from my system using yum remove java*.
Then I have installed Oracle Java i.e. jdk1.8.0_151 using standard methods i.e.

1. Download the .tar.gz and then unzip the same.

2. Change in /etc/profile and set the JAVA_HOME as follows:

   export JAVA_HOME=/usr/java/jdk1.8.0_151
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

3. Then source /etc/profile

After this when I type java -version I got Segmentation Fault (core dumped). When I type which java I got

/usr/bin/java

Note:

I had removed all symlinks of java and again created. Eg.

ln -s /usr/java/jdk1.8.0_151/bin.java /usr/bin/java 

and then

ln -s /usr/jdk1.8.0_151/bin.java /etc/alternatives/java

Post that I have tried

update-alternatives --install /usr/bin/java java 
/usr/java/jdk1.8.0_151/bin/java 1

Nothing happend!!! I still see that frustrating message when I check Java Version. Segmentation Fault (core dumped).

Can any body please share any light or thought on why is this happening?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/.cache. Просто удалите папки программы и попробуйте снова ее запустить. Если и это не помогло, вы можете попробовать полностью удалить программу, а потом снова ее установить, возможно, какие-нибудь зависимости были повреждены:

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

Источник

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

Использую RH7б 2.6.22 Скомпилил программу без хитрых опций gcc 4.1.1, всё собралось ок.

Запуская программу, система пишет «ошибка сегментирования». Что это значит? Как локализовать ошибку?

Re: gcc: ошибка сегментирования

Re: gcc: ошибка сегментирования

Re: gcc: ошибка сегментирования

телепаты в отпуске, давай сорсы. Ищи траблы с указателями/переполнениями/etc 🙂

Re: gcc: ошибка сегментирования

Это значит, что твоя программа полезла в чужой сегмент памяти. Возможно из-за кривого указателя, выхода за предел массива etc.

Re: gcc: ошибка сегментирования

> Как локализовать ошибку?

Re: gcc: ошибка сегментирования

Сорцы простые printf( «dddn» ); return( 0 ) Правда ещё включается масса *.h файлов из Minix3 и после return( 0 ) идёт код.

Мне кажется компилятор сделал бинарник, который операционка выполнить не может. Мне не понятно почему. Хитрых опций при компиляции нет.

Создаётся ощущение, что есть в *.h файлах миникса заданы препроцессорные директивы, которые заставляют gcc создавать не вменяемый бинарник. Может я ошибаюсь, толкните на путь истинный.

Re: gcc: ошибка сегментирования

Кажется понял где копать. Всем спасибо за наводку.

Re: gcc: ошибка сегментирования

Re: gcc: ошибка сегментирования

Нету функции collect2 в библиотеки libc.a
ld не может собрать бинарник

Re: gcc: ошибка сегментирования

В исходниках нет ссылки на collect2

Re: gcc: ошибка сегментирования

Ни когда не встречал такой ошибки.

Re: gcc: ошибка сегментирования

Re: gcc: ошибка сегментирования

Он разве не находит тредовые функции? Он вроде не чтото другое ругается.

Re: gcc: ошибка сегментирования

> Он разве не находит тредовые функции? Он вроде не чтото другое ругается.

Что bt на корке показывает?

Re: gcc: ошибка сегментирования

Re: gcc: ошибка сегментирования

Очевидно или с либами вашими что-то не то или юзаете вы их как-то не так.

Re: gcc: ошибка сегментирования

>Очевидно или с либами вашими что-то не то или юзаете вы их как-то не так.

Источник

[проблемы из ниоткуда] ошибка сегментирования. как найти причину?

полагаю что дело в том что утром были найдены ошибки в файловой системе

то есть вроде бы читает файл и после этого падает. но толку.. ltrace вообще ничего не дал. похоже ошибка происходит непосредственно в коде программы ssh. ещё вчера всё работало..

1) Посмотри, нет ли записей о сегфолтах в messages.
2) Попробуй временно переименовать

ltrace ssh svn-server

Ну явно же написано, что у тебя known_hosts покоцан. Сдвинь его в сторонку и не парься.

Но таки программа не должна падать из-за проблемы в каком-то конфиге.

благодарю за толковые советы

не, я ж написал, ltrace ничего не дал:

да, кстати, вряд ли.. но я тем не менее сдвинул его.. не помогло..

можно ли как-то запустить проверку контрольных сумм всех файлов установленных пакетным менеджером?

Запустить под gdb и посмотреть почему упало.

>не, я ж написал, ltrace ничего не дал:

strace ssh svn-server

chkrootkit и rkhunter попробуй

и работал вчера ssh

ну и странно что на одном и том же месте.. скорее уж с диском проблемы..

мужик, я думаю специально для тебя нужно ввести звание Ъ^2.

Где,ж он на ровном месте? Какова вероятность, что при многочисленных попытках считать файл он всегда будет попадать на битую область?

> ну и странно что на одном и том же месте..

У меня эта штука половину портов засосала. 1111 А дело всё было в слоте памяти на материнке. И memtest86+ молчал.

libc переставь и tls и прочие либы, которыми пользуется ssh. переустановка только ssh не приведет к переустановке этих либ

Хехе. вероятная причина кроется в svn.

Сам лично сталкивался с регулярными падениями СВН составляющих в дебе. Как правило это происходило при попытке СВНа обратиться в дбасу. Но и в других ситуациях тоже, но реже.

> Хехе. вероятная причина кроется в svn.

open(«/home/andrey/.ssh/known_hosts», O_RDONLY) = 4 ★ ( 26.09.11 14:35:24 )

read() отработал нормально. Проблема где-то доальше в коде. Надо gdb.

Ага, я тоже сидел с gdb и дебажил почему svn up падает 🙂 Проблема была глубоко-глубоко 🙂 А на деле все оказалось куда проще.

Там цикл чтения по 4096. Еслибы он отработал нормально, мы бы увидели следующую итерацию (размер файла больше).

memtest’ом можно подтереться только. Инфа 100%.

Для таких вещей есть ключ для дебага. И gdb. И ещё strace.

А ещё подумай о том, что повреждение может быть в какой-то либе, которую он загружает.

Источник

Ошибка сегментирования (APT)

В общем имеется вдс с дебианом(etch), со вчерашнего дня при попытке как либо заюзать apt-get (or aptitude) выдает «ошибка сегментирования». пример: stvlad:/home/stvad# aptitude Ouch! Got SIGSEGV, dying.. Ошибка сегментирования либо же в случае с апт гетом stvlad:/home/stvad# apt-get install subversion Ошибка сегментирования. 0% подскажите в чем дело? и как это исправить..

Re: Ошибка сегментирования (APT)

что перед этим менялось? попробуй почистить кеш апта и заново apt-get update сделать.

Re: Ошибка сегментирования (APT)

щас попробую, отпишусь что менялось точноне помню помню поставил питон, htop, mc.

Re: Ошибка сегментирования (APT)

Re: Ошибка сегментирования (APT)

ldd `which aptitude`

Или это не бинарник?

Re: Ошибка сегментирования (APT)

вообще то бинарник )
На Ленни выдаст вот

$ldd `which aptitude`
linux-gate.so.1 => (0xffffe000)
libapt-pkg-libc6.7-6.so.4.6 => /usr/lib/libapt-pkg-libc6.7-6.so.4.6 (0xb7e63000)
libncursesw.so.5 => /lib/libncursesw.so.5 (0xb7e25000)
libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0xb7e1e000)
libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0xb7d5a000)
libept.so.0 => /usr/lib/libept.so.0 (0xb7c99000)
libxapian.so.15 => /usr/lib/libxapian.so.15 (0xb7b43000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7b30000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7b18000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7a32000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7a09000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb79fc000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb78a7000)
libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb78a3000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb789e000)
/lib/ld-linux.so.2 (0xb7f47000)

Re: Ошибка сегментирования (APT)

удалил кеш. загрузило индексы и снова выдало ошибку сигментирования.

Re: Ошибка сегментирования (APT)

попробуйте сделать strace на аптитуду, хоть видно будет на загрузке какого файла оно падает

Re: Ошибка сегментирования (APT)

Признавайся, добавлял репозитарии Lenny или Sid?

Re: Ошибка сегментирования (APT)

признаюсь добавлял и работало))) потом перестало((( в них причина?

Re: Ошибка сегментирования (APT)

ну и надо было перееждать на ленни уже.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

sudo apt update
sudo apt full-upgrade

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

/.cache. Просто удалите папки программы и попробуйте снова ее запустить. Если и это не помогло, вы можете попробовать полностью удалить программу, а потом снова ее установить, возможно, какие-нибудь зависимости были повреждены:

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

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

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

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

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

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

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

(gdb) attach ваш_pid

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

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

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

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

(gdb) detach
(gdb) quit

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

Выводы

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

Оцените статью:

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

7 комментариев

Спасибо, было очень интересно почитать про отладчик.

На самом деле от этого избавится я не могу. Остаётся мне всё сваливать на свой старый компьютер с 1024 мегабайтами озу. Постоянные ошибки сегментирования когда комплимирую какую-либо программу. Чтобы скомплимировать ядро надо по миллиону раз вводить make!! Щас выкину комп и куплю новый и думаю проблема сама разрешится.

Gentoo. cmake 3.14.6. Segmentation fault.
Xeon 2620 v2 24Gb ram

Проблема сама не решается почему-то. 8-(

С ошибкой SIGSEGV или так называемой ошибкой сегментации(на самом деле это ошибки обращения с памятью) вы ничё не сможете сделать. если вы юзер, а не разработчик и она возникает в вашей проге. можете только одного не запускать эту прогу удалить её или попытаться обновить, возможно(вовсе не обязательно!) её заметили и исправили. Но вообще лицензионное соглашение по Ubuntu вас предупреждает, что вы пользуетесь системой в которой софт вовсе не обязан работать и никто за это не отвечает. вы это делаете на свой страх и риск! это краткий его перевод. А если вы купили операционку заплатили бабки и заказали техподдержку, то вы тогда уже имеете право обратиться в службу тех поддержки сообщить баг, где и как он возникает и они обязаны не просто испавить его прислав патч, но так же всем таким как вы кто заплатил. Иначе вы имеете право подать на них в суд и они обязаны компенсировать вам убытки. Но это не Ubuntu. Обратная сторона медали свободного по и бесплатных операционок. среди Линуксовых есть AIX(только платная+ техподдержка), SUSE(не путать с Open Suse) и Debian(есть free урезаный вариант и нормальный платный). Это оч серьёзная ошибка краеугольный камень всех программ и работы компа в целом. Если это ломается, то всё летит к чёрту. Конечно они стараюстся и сразу посылать вас не будут. Это их репутация! но вообще дело в програмерах. Щаз стало оч много криворуких. Вот я смотрю на их код и удивляюсь, как можно так безалаберно писать проги! Если бы вы только это видели вы бы не удивились почему всё так плохо работает. Встречаются такие кадры которые всё только портят! ну а что програмеров не хаватет, делать надо много вот и берут всех подряд. А потом начинается. Если конечно это заметили до релиза, то ладно. Но тут всё ещё зависит от тестеров. Если они хорошие то найдут баги вовремя до релиза и исправят. но у нас как бывает. Отдела тестирования нет, сэкономили.. Тестер дай бог 2-3 а то часто 1 вообще. В программе всегда много ошибок. Особенно вначале. все мы ошибаемся, особенно некоторые. Причина? Нехватка мозгов или банально невнимательность. поэтому все проги должны быть тщательнейшим образом оттестированы. только тогда она может быть допущена к релизу. А ещё заказчик подгоняет. Хорошую прогу нельзя написать в спешке. тем более большую. Такие ошибки как оч трудно найти, а если она не всегда воспроизводится, так вообще нереально, Если только случайно наткнёшься. Потому что как бывает один раз вылетела, а второй нет и пошла дальше и норм. Или пошла дальше и всё стало неправильным. с програмой начинают твориться чудеса. это всё та же ошибка с памятью, которая всё портит. Вылететь может не только ваша прога но и вся система. Но даже если она стабильно воспроизводится, то на её поиск может понадобиться дни а может и неделя две кропотливой упорной работы, носящей изнуряющий характер. искать будут всем отделом. но её тогда по крайней мере можно найти. а если нет. то вам поможет только чудо. А уж что сделают после этого с тем кто это сделал я даже не знаю! Вот такие вот они эти ошибки сегментации. Я показал то что там происходит за кадром юзера.

У меня появляется такая ошибка при попытке запуска Viber

Источник