Ошибка шины стек памяти сброшен на диск

я написал вот такую программку:

//includes
#include <iostream>
#include <chrono>
#include <string>
#include <ctime>

//namespaces
using namespace std;
using namespace chrono;

//defines
#define RETURN return 0

//main
int main() {
    setlocale(LC_ALL,"ru"); //locale
    const auto _BEFORE_ = high_resolution_clock::now(); //start timer (for time account)
    srand(time(0));

    //Create Array
    int CountArrayIn_arr2D = 2;
    int CountElementsIn_arr1D = 3;
    int **arr2D = new int*[CountArrayIn_arr2D];

    //Generate Array
    for(int i = 0; i < CountArrayIn_arr2D; i++) {
        for(int j = 0; j < CountElementsIn_arr1D; j++) {
            arr2D[i][j] = rand() % 30 + 1;
        }
    }

    //Print Array
    for(int i = 0; i < CountArrayIn_arr2D; i++) {
        for(int j = 0; j < CountElementsIn_arr1D; j++) {
            cout<<"\033[34m"<<arr2D[i][j]<<"\033[0m\t";
        }
        cout<<endl;
    }


    /*Clean memory*/
    for(int i = 0; i < CountArrayIn_arr2D; i++) {
        delete[] arr2D[i];
    }
    delete[] arr2D;

    //time account
    const auto _AFTER_ = high_resolution_clock::now();
    const float TIME_FOR_PROGRAM = duration_cast<milliseconds>(_AFTER_-_BEFORE_).count();
    cout<<"\n\n Programm completed in "<<TIME_FOR_PROGRAM<<"ms"<<endl;
    RETURN;
}

и пишет: запуск программы(не компиляция, а запуск) на Ubuntu

у меня 2 вопроса.
1) что значит стек сброшен на диск? на жесткий диск? удалится ли он самостоятельно? если нет то как удалить?
2) как это решить и почему это вообще произошло?

задан 29 окт 2019 в 14:44

Данил Перелыгин's user avatar

Данил ПерелыгинДанил Перелыгин

1301 золотой знак1 серебряный знак8 бронзовых знаков

2

«Стек памяти сброшен на диск» — это [весьма-а вольный] перевод фразы «Core dumped». На диске в текущем каталоге создаётся файл с именем «core». Сам он не удалится, но он — самый обычный файл, который вы можете удалить когда захотите.

Файл core также сам по себе является кратчайшим путём к ответу на вопрос номер 2. Если ваш бинарник собран с опцией компилятора «-g», то вы можете запустить отладчик с командной строкой в виде «gdb -c core main.exe». Отладчик автоматически окажется на той строке, которая вызвала segmentation fault. О работе в gdb рекомендую почитать его документацию, она обширна и исчерпывающа.

ответ дан 29 окт 2019 в 15:03

user_587's user avatar

user_587user_587

2,5411 золотой знак11 серебряных знаков20 бронзовых знаков

5

У вас явная ошибка работы с памятью. Вызов new происходит один раз, а вызов delete?


Здесь происходит выделение массива указателей на int:

int **arr2D = new int*[CountArrayIn_arr2D];

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

for (int i = 0; i < CountArrayIn_arr2D; i++) 
{
    arr2D[i] = new int[CountElementsIn_arr1D];
//             ^^^^^^^

    for (int j = 0; j < CountElementsIn_arr1D; j++) 
    {
        // делаем что нужно
    }
}

ответ дан 29 окт 2019 в 14:51

Bogdan's user avatar

1

чел, ты забыл объявить элементы массивов в массиве)

ответ дан 29 окт 2019 в 14:55

jbc dgb's user avatar

Не всегда программы в 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

segfault

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

segfault1

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

(gdb) backtrace

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

(gdb) detach
(gdb) quit

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

Выводы

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

Creative Commons License

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Содержание

  1. Ошибка сегментирования Ubuntu
  2. Что такое ошибка сегментации?
  3. Почему возникает ошибка сегментации?
  4. Что делать если возникла ошибка сегментирования?
  5. Выводы
  6. Оцените статью:
  7. Об авторе
  8. 7 комментариев
  9. Ошибка сегментирования Ubuntu
  10. Что такое ошибка сегментации?
  11. Почему возникает ошибка сегментации?
  12. Что делать если возникла ошибка сегментирования?
  13. Выводы
  14. [проблемы из ниоткуда] ошибка сегментирования. как найти причину?
  15. Segmentation Fault (распределение памяти компьютера)
  16. Немного истории
  17. Совместный доступ к ресурсам
  18. Адресное пространство
  19. Виртуализация памяти
  20. Переадресация
  21. Перераспределение памяти
  22. Сегментация памяти
  23. Совместное использование сегментов
  24. Ограничения сегментации
  25. Разбиение памяти на страницы
  26. Буфер быстрой переадресации (TLB, Translation-lookaside Buffer)

Ошибка сегментирования 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

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

segfault

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

segfault1

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

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

(gdb) detach
(gdb) quit

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

Выводы

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

gedit8

blackscreen2 2

system program Problem detected

resolve5

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

Об авторе

Основатель и администратор сайта 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

Источник

Ошибка сегментирования 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:

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

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

oshibka segmentirovanija ubuntu 1

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

oshibka segmentirovanija ubuntu 2

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

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

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

Выводы

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

Источник

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

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

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

56076:1404038575

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

34387: 474426391

ltrace ssh svn-server

23359:317419500

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

40790:481586867

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

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

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

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

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

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

25540:527665789

17727:1795121613

34387: 474426391

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

strace ssh svn-server

chkrootkit и rkhunter попробуй

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

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

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

23359:317419500

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

23359:317419500

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

87623: 1228661212

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

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

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

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

23359:317419500

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

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

p

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

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

23359:317419500

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

34387: 474426391

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

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

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

Источник

Segmentation Fault (распределение памяти компьютера)

2254da58f07d4d69b4733304c85989e2

Когда я делаю ошибку в коде, то обычно это приводит к появлению сообщения “segmentation fault”, зачастую сокращённого до “segfault”. И тут же мои коллеги и руководство приходят ко мне: «Ха! У нас тут для тебя есть segfault для исправления!» — «Ну да, виноват», — обычно отвечаю я. Но многие ли из вас знают, что на самом деле означает ошибка “segmentation fault”?

Чтобы ответить на этот вопрос, нам нужно вернуться в далёкие 1960-е. Я хочу объяснить, как работает компьютер, а точнее — как в современных компьютерах осуществляется доступ к памяти. Это поможет понять, откуда же берётся это странное сообщение об ошибке.

Вся представленная ниже информация — основы компьютерной архитектуры. И без нужды я не буду сильно углубляться в эту область. Также я буду применять всем известную терминологию, так что мой пост будет понятен всем, кто не совсем на «вы» с вычислительной техникой. Если же вы захотите изучить вопрос работы с памятью подробнее, то можете обратиться к многочисленной доступной литературе. А заодно не забудьте покопаться в исходном коде ядра какой-нибудь ОС, например, Linux. Я не буду излагать здесь историю вычислительной техники, некоторые вещи не будут освещаться, а некоторые сильно упрощены.

Немного истории

image loader

То есть на ОС приходилась, скажем, четверть всей доступной памяти, а остальной объём отдавался под пользовательские задачи. В то время роль ОС заключалась в простом управлении оборудованием с помощью прерываний ЦПУ. Так что операционке нужна была память для себя, для копирования данных с устройств и для работы с ними (режим PIO). Для вывода данных на экран нужно было использовать часть основной памяти, ведь видеоподсистема либо не имела своей оперативки, либо обладала считанными килобайтами. А уже сама программа выполнялась в области памяти, идущей сразу после ОС, и решала свои задачи.

Совместный доступ к ресурсам

Из-за непомерной стоимости мало кто мог позволить себе приобрести сразу несколько компьютеров, чтобы обрабатывать одновременно несколько задач. Поэтому люди начали искать способы совместного доступа к вычислительным ресурсам одного компьютера. Так наступила эра многозадачности. Обратите внимание, что в те времена ещё никто не помышлял о многопроцессорных компьютерах. Так как же можно заставить компьютер с одним ЦПУ выполнять несколько разных задач?

Решением стало использование планировщика задач (scheduling): пока один процесс прерывался, ожидая завершения операций ввода/вывода, ЦПУ мог выполнять другой процесс. Я не буду здесь больше касаться планировщика задач, это слишком обширная тема, не имеющая отношения к памяти.

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

image loader

Задачи А и В хранятся в памяти, поскольку копировать их на диск и обратно слишком затратно. И по мере того, как процессор выполняет ту или иную задачу, он обращается к памяти за соответствующими данными. Но тут возникает проблема.

Когда один программист будет писать код для выполнения задачи В, он должен знать границы выделяемых сегментов памяти. Допустим, задача В занимает в памяти отрезок от 10 до 12 Кб, тогда каждый адрес памяти должен быть жёстко закодирован в пределах этих границ. Но если компьютер будет выполнять сразу три задачи, то память будет поделена на большее количество сегментов, и значит сегмент для задачи В может оказаться сдвинут. Тогда код программы придётся переписывать, чтобы она могла оперировать меньшим объёмом памяти, а также изменить все указатели.

Здесь всплывает и иная проблема: что если задача В обратится к сегменту памяти, выделенному для задачи А? Такое легко может произойти, ведь при работе с указателями памяти достаточно сделать маленькую ошибку, и программа будет обращаться к совершенно другому адресу, нарушив целостность данных другого процесса. При этом задача А может работать с очень важными с точки зрения безопасности данными. Нет никакого способа помешать В вторгнуться в область памяти А. Наконец, вследствие ошибки программиста задача В может перезаписать область памяти ОС (в данном случае от 0 до 4 Кб).

Адресное пространство

Чтобы можно было спокойно выполнять несколько задач, хранящихся в памяти, нам нужна помощь от ОС и оборудования. В частности, адресное пространство. Это некая абстракция памяти, выделяемая ОС для какого-то процесса. На сегодняшний день это фундаментальная концепция, которая используется везде. По крайней мере, во ВСЕХ компьютерах гражданского назначения принят именно этот подход, а у военных могут быть свои секреты. Персоналки, смартфоны, телевизоры, игровые приставки, умные часы, банкоматы — ткните в любой аппарат, и окажется, что распределение памяти в нём осуществляется по принципу «код-стек-куча» (code-stack-heap).

Адресное пространство содержит всё, что нужно для выполнения процесса:

image loader

Виртуализация памяти

Допустим, задача А получила в своё распоряжение всю доступную пользовательскую память. И тут возникает задача В. Как быть? Решение было найдено в виртуализации.

Напомню одну из предыдущих иллюстраций, когда в памяти одновременно находятся А и В:

image loader

Допустим, А пытается получить доступ к памяти в собственном адресном пространстве, например по индексу 11 Кб. Возможно даже, что это будет её собственный стек. В этом случае ОС нужно придумать, как не подгружать индекс 1500, поскольку по факту он может указывать на область задачи В.

На самом деле, адресное пространство, которое каждая программа считает своей памятью, является памятью виртуальной. Фальшивкой. И в области памяти задачи А индекс 11 Кб будет фальшивым адресом. То есть — адресом виртуальной памяти.

Каждая программа, выполняющаяся на компьютере, работает с фальшивой (виртуальной) памятью. С помощью некоторых чипов ОС обманывает процесс, когда он обращается к какой-либо области памяти. Благодаря виртуализации ни один процесс не может получить доступ к памяти, которая ему не принадлежит: задача А не влезет в память задачи В или самой ОС. При этом на пользовательском уровне всё абсолютно прозрачно, благодаря обширному и сложному коду ядра ОС.

Таким образом, каждое обращение к памяти регулируется операционной системой. И это должно осуществляться очень эффективно, чтобы не слишком замедлять работу различных выполняющихся программ. Эффективность обеспечивается с помощью аппаратных средств, преимущественно — ЦПУ и некоторых компонентов вроде MMU. Последний появился в виде отдельного чипа в начале 1970-х, а сегодня MMU встраиваются непосредственно в процессор и в обязательном порядке используются операционными системами.

Вот небольшая программка на С, демонстрирующая работу с адресами памяти:

На моей машине LP64 X86_64 она показывает такой результат:

Code is at 0x40054c
Stack is at 0x7ffe60a1465c
Heap is at 0x1ecf010

Как я и описывал, сначала идёт кодовый сегмент, затем куча, а затем стек. Но все эти три адреса фальшивые. В физической памяти по адресу 0x7ffe60a1465c вовсе не хранится целочисленная переменная со значением 3. Никогда не забывайте, что все пользовательские программы манипулируют виртуальными адресами, и только на уровне ядра или аппаратных драйверов допускается использование адресов физической памяти.

Переадресация

Переадресация (транслирование, перевод, преобразование адресов) — это термин, обозначающий процесс сопоставления виртуального адреса физическому. Занимается этим модуль MMU. Для каждого выполняющегося процесса операционка должна помнить соответствия всех виртуальных адресов физическим. И это довольно непростая задача. По сути, ОС приходится управлять памятью каждого пользовательского процесса при каждом обращении. Тем самым она превращает кошмарную реальность физической памяти в полезную, мощную и лёгкую в использовании абстракцию.

Давайте рассмотрим подробнее.

Итак, это виртуальное адресное пространство:

image loader

А это его физический образ:

image loader

Физический адрес = виртуальный адрес + base

Если получившийся физический адрес (6 Кб) выбивается из границ выделенной области (4—20 Кб), это означает, что процесс пытается обратиться к памяти, которая ему не принадлежит. Тогда ЦПУ генерирует исключение и сообщает об этом ОС, которая обрабатывает данное исключение. В этом случае система обычно сигнализирует процессу о нарушении: SIGSEGV, Segmentation Fault. Этот сигнал по умолчанию прерывает выполнение процесса (это можно настраивать).

Перераспределение памяти

Если задача А исключена из очереди на выполнение, то это даже лучше. Это означает, что планировщик попросили выполнить другую задачу (допустим, В). Пока выполняется В, операционка может перераспределить всё физическое пространство задачи А. Во время выполнения пользовательского процесса ОС зачастую теряет управление процессором. Но когда процесс делает системный вызов, процессор снова возвращается под контроль ОС. До этого системного вызова операционка может что угодно делать с памятью, в том числе и целиком перераспределять адресное пространство процесса в другой физический раздел.

В нашем примере это осуществляется достаточно просто: ОС перемещает 16-килобайтную область в другое свободное место подходящего размера и просто обновляет значения переменных base и bounds для задачи А. Когда процессор возвращается к её выполнению, процесс переадресации всё ещё работает, но физическое адресное пространство уже изменилось.

С точки зрения задачи А ничего не меняется, её собственное адресное пространство по-прежнему расположено в диапазоне 0-16 Кб. При этом ОС и MMU полностью контролируют каждое обращение задачи к памяти. То есть программист манипулирует виртуальной областью 0-16 Кб, а MMU берёт на себя сопоставление с физическими адресами.

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

image loader

Программисту теперь не нужно заботиться о том, с какими адресами памяти будет работать его программа, не нужно переживать о конфликтах. ОС в связке с MMU снимают с него все эти заботы.

Сегментация памяти

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

Для решения некоторых из этих проблем давайте рассмотрим более сложную систему организации памяти — сегментацию. Смысл её прост: принцип “base and bounds” распространяется на все три сегмента памяти — кучу, кодовый сегмент и стек, причём для каждого процесса, вместо того чтобы рассматривать образ памяти как единую уникальную сущность.

В результате мы больше не теряем память между стеком и кучей:

image loader

Допустим, у кучи задачи А параметр base равен 126 Кб, а bounds — 2 Кб. Пусть задача А обращается к виртуальному адресу 3 Кб (в куче). Тогда физический адрес определяется как 3 – 2 Кб (начало кучи) = 1 Кб + 126 Кб (сдвиг) = 127 Кб. Это меньше 128, а значит ошибки обращения не будет.

Совместное использование сегментов

Сегментирование физической памяти не только не позволяет виртуальной памяти отъедать физическую, но также даёт возможность совместного использования физических сегментов с помощью виртуальных адресных пространств разных процессов.

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

image loader

При этом оба процесса не подозревают, что делят с кем-то свою память. Такой подход стал возможен благодаря внедрению битов защиты сегмента (segment protection bits).

Поскольку сам код нельзя модифицировать, то все кодовые сегменты создаются с флагами RX. Это значит, что процесс может загружать эту область памяти для последующего выполнения, но в неё никто не может записывать. Другие два сегмента — куча и стек — имеют флаги RW, то есть процесс может считывать и записывать в эти свои два сегмента, однако код из них выполнять нельзя. Это сделано для обеспечения безопасности, чтобы злоумышленник не мог повредить кучу или стек, внедрив в них свой код для получения root-прав. Так было не всегда, и для высокой эффективности этого решения требуется аппаратная поддержка. В процессорах Intel это называется “NX bit”.

Флаги могут быть изменены в процессе выполнения программы, для этого используется mprotect().

Под Linux все эти сегменты памяти можно посмотреть с помощью утилит /proc//maps или /usr/bin/pmap.

Здесь есть все необходимые подробности относительно распределения памяти. Адреса виртуальные, отображаются разрешения для каждой области памяти. Каждый совместно используемый объект (.so) размещён в адресном пространстве в виде нескольких частей (обычно код и данные). Кодовые сегменты являются исполняемыми и совместно используются в физической памяти всеми процессами, которые разместили подобный совместно используемый объект в своём адресном пространстве.

Shared Objects — это одно из крупнейших преимуществ Unix- и Linux-систем, обеспечивающее экономию памяти.

Также с помощью системного вызова mmap() можно создавать совместно используемую область, которая преобразуется в совместно используемый физический сегмент. Тогда у каждой области появится индекс s, означающий shared.

Ограничения сегментации

Итак, сегментация позволила решить проблему неиспользуемой виртуальной памяти. Если она не используется, то и не размещается в физической памяти благодаря использованию сегментов, соответствующих именно объёму используемой памяти.

Но это не совсем верно.

Допустим, процесс запросил у кучи 16 Кб. Скорее всего, ОС создаст в физической памяти сегмент соответствующего размера. Если пользователь потом освободит из них 2 Кб, тогда ОС придётся уменьшить размер сегмента до 14 Кб. Но вдруг потом программист запросит у кучи ещё 30 Кб? Тогда предыдущий сегмент нужно увеличить более чем в два раза, а возможно ли это будет сделать? Может быть, его уже окружают другие сегменты, не позволяющие ему увеличиться. Тогда ОС придётся искать свободное место на 30 Кб и перераспределять сегмент.

image loader

Главный недостаток сегментов заключается в том, что из-за них физическая память сильно фрагментируется, поскольку сегменты увеличиваются и уменьшаются по мере того, как пользовательские процессы запрашивают и освобождают память. А ОС приходится поддерживать список свободных участков и управлять ими.

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

ОС может попытаться разместить данные компактнее, объединяя все свободные области в один большой чанк, который в дальнейшем можно использовать для нужд новых процессов и перераспределения.

image loader

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

Так что сегментация памяти влечёт за собой немало проблем, связанных с управлением памятью и многозадачностью. Нужно как-то улучшить возможности сегментации и исправить недостатки. Это достигается с помощью ещё одного подхода — страниц виртуальной памяти.

Разбиение памяти на страницы

Как было сказано выше, главный недостаток сегментации заключается в том, что сегменты очень часто меняют свой размер, и это приводит к фрагментации памяти, из-за чего может возникнуть ситуация, когда ОС не выделит для процессов нужные области памяти. Эта проблема решается с помощью страниц: каждое размещение, которое ядро делает в физической памяти, имеет фиксированный размер. То есть страницы — это области физической памяти фиксированного размера, ничего более. Это сильно облегчает задачу управления свободным объёмом и избавляет от фрагментации.

Давайте рассмотрим пример: виртуальное адресное пространство объёмом 16 Кб разбито на страницы.

image loader

Мы не говорим здесь о куче, стеке или кодовом сегменте. Просто делим память на куски по 4 Кб. Затем то же самое делаем с физической памятью:

image loader

ОС хранит таблицу страниц процесса (process page table), в которой представлены взаимосвязи между страницей виртуальной памяти процесса и страницей физической памяти (страничный кадр, page frame).

image loader

Теперь мы избавились от проблемы поиска свободного места: страничный кадр либо используется, либо нет (unused). И ядру не в пример легче найти достаточное количество страниц, чтобы выполнить запрос процесса на выделение памяти.

Страница — это мельчайшая и неделимая единица памяти, которой может оперировать ОС.

У каждого процесса есть своя таблица страниц, в которой представлена переадресация. Здесь уже используются не значения границ области, а номер виртуальной страницы (VPN, virtual page number) и сдвиг (offset).

Пример: размер виртуального пространства 16 Кб, следовательно, нам нужно 14 бит для описания адресов (2 14 = 16 Кб). Размер страницы 4 Кб, значит нам нужно 4 Кб (16/4), чтобы выбрать нужную страницу:

image loader

Когда процесс хочет использовать, например, адрес 9438 (вне границ 16 384), то он запрашивает в двоичном коде 10.0100.1101.1110:

image loader

Это 1246-й байт в виртуальной странице номер 2 («0100.1101.1110»-й байт в «10»-й странице). Теперь ОС достаточно просто обратиться к таблице страниц процесса, чтобы найти эту страницу номер 2. В нашем примере она соответствует восьмитысячному байту физической памяти. Следовательно, виртуальный адрес 9438 соответствует физическому адресу 9442 (8000 + сдвиг 1246).

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

Если сами таблицы страниц хранятся в памяти, то для получения VPN надо обращаться к памяти. Тогда количество обращений к ней удваивается: сначала мы извлекаем из памяти номер нужной страницы, а затем обращаемся к самим данным, хранящимся в этой странице. И если скорость доступа к памяти невелика, то ситуация выглядит довольно грустно.

Буфер быстрой переадресации (TLB, Translation-lookaside Buffer)

Использование страниц в качестве основного инструмента поддержки виртуальной памяти может привести к сильному снижению производительности. Разбиение адресного пространства на небольшие куски (страницы) требует хранения большого количества данных о размещении страниц. А раз эти данные хранятся в памяти, то при каждом обращении процесса к памяти осуществляется ещё одно, дополнительное обращение.

Для поддержания производительности снова используется помощь оборудования. Как и при сегментации, мы аппаратными методами помогаем ядру эффективно осуществлять переадресацию. Для этого используется TLB, входящий в состав MMU, и представляющий собой простой кэш для некоторых VPN-переадресаций. TLB позволяет ОС не обращаться к памяти лишний раз, чтобы получить физический адрес из виртуального.

Аппаратный MMU инициируется при каждом обращении к памяти, извлекает из виртуального адреса VPN и запрашивает у TLB, хранится ли в нём переадресация с этого VPN. Если да, то его роль выполнена. Если нет, то MMU находит нужную таблицу страниц процесса, и если она ссылается на валидный адрес, то обновляет данные в TLB, чтобы тот предоставлял их при следующем обращении.

Как вы понимаете, если в кэше отсутствует нужная переадресация, то это замедляет обращение к памяти. Можно предположить, что чем больше размер страниц, тем больше вероятность, что в TLB окажутся нужные данные. Но тогда мы будем тратить больше памяти на каждую страницу. Так что здесь нужен какой-то компромисс. Современные ядра умеют использовать страницы разных размеров. Например, Linux способен оперировать «огромными» страницами по 2 Мб вместо традиционных 4 Кб.

Также рекомендуется хранить данные компактно, в смежных адресах памяти. Если вы раскидаете их по всей памяти, то куда чаще в TLB не будет обнаруживаться нужной переадресации, либо он будет постоянно переполняться. Это называется эффективностью пространственной локальности (spacial locality efficiency): данные, которые расположены в памяти сразу за вашими, могут размещаться в той же физической странице, и тогда благодаря TLB вы получите выигрыш в производительности.

Кроме того, TLB в каждой записи хранит так называемые ASID (Address Space Identifier, идентификатор адресного пространства). Это нечто вроде PID, идентификатора процесса. Каждый процесс, поставленный в очередь на выполнение, имеет собственный ASID, и TLB может управлять обращением любого процесса к памяти, без риска ошибочных обращений со стороны других процессов.

Повторимся снова: если пользовательский процесс пытается обратиться к неправильному адресу, тот наверняка будет отсутствовать в TLB. Следовательно, будет запущена процедура поиска в таблице страниц процесса. В ней хранится переадресация, но с неправильным набором битов. В х86-системах переадресации имеют размер 4 Кб, то есть битов в них немало. А значит есть вероятность найти правильный бит, равно как и другие вещи, наподобие бита изменения («грязного бита», dirty bit), битов защиты (protection bit), бита обращения (reference bit) и т.д. И если запись помечена как неправильная, то ОС по умолчанию выдаст SIGSEGV, что приведёт к ошибке “segmentation fault”, даже если о сегментах уже и речи не идёт.

На самом деле разбиение памяти на страницы в современных ОС устроено куда сложнее, чем я расписал. В частности, используются многоуровневые записи в таблицах страниц, многостраничные размеры, вытеснение страниц (page eviction), также известное как «обмен» (ядро скидывает страницы из памяти на диск и обратно, что повышает эффективность использования основной памяти и создаёт у процессов иллюзию её неограниченности).

Источник

  • Печать

Страницы: [1]   Вниз

Тема: Ошибка сегментирования (стек памяти сброшен на диск) [Решено]  (Прочитано 11912 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
DANNNNN

Привет всем.
Есть программа. Она устанавливается из архива, который предварительно скачивается и после устанавливается.

Программа очень специфичная. Ты ей подсовываешь файл с командами, она его рассчитывает ( математического уклона программа) и выдаёт файл типа out.
И вот вчера при попытке запустить программу она выдаёт:

dan@dan-B450-AORUS-PRO:~/opt/2$ $GAUSS_EXEDIR/g16 NiFeSi2New33.inp
 Unable to open input file "NiFeSi2New33.inp" or "NiFeSi2New33.inp".
Ошибка сегментирования (стек памяти сброшен на диск)
Естественно у меня всего один файл в папке из которой происходит запуск.
Что я делал. Я на создавал кучу входных файлов ( вот этот 3-ий был) и всё  равно прога почему-то видит какой-то второй такой- же файл.  :D

Я обновлял Ubuntu, я перестановил программу поверх старой. Ничего не помогает(.
Помогите кто чем может.

« Последнее редактирование: 18 Марта 2020, 11:41:50 от zg_nico »


Онлайн
bezbo

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

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

Помогите кто чем может

вам остается только отправить отчет об ошибке разработчикам

или запустите программу отладчиком sudo gdb -q


Оффлайн
ReNzRv

И вот вчера

До этого система обновлялась?
Автоматическое обновление системы включено в настройках?


Оффлайн
DANNNNN

Проблема решилась(

Очень странно. Но я взял файл, который до этого запускался и немного изменил в неём параметры на те которые нужны. И всё заработало.

До этого файлы были созданы как копии того файла, который был создан на другом ПК и перенесён на этот комп через флэшку. Все копии этого файла и выдавали ошибку, не смотря на то, что некоторые из них также я переносил и на другие диски, там редактриовали переносил обратно.

Что это было- не понятно.
Короче ошибка в файле О_о.

Системе обновлялась конечно же.

P.S. До написание сюда я просидел часов 5 над проблемой.

« Последнее редактирование: 16 Ноября 2019, 10:18:29 от DANNNNN »


Оффлайн
andytux

«Разруха в головах, а не в клозетах.»

перенесён на этот комп через флэшку. …Короче ошибка в файле

Права на файл.


  • Печать

Страницы: [1]   Вверх

Не всегда программы в 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

segfault

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

segfault1

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

(gdb) backtrace

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

(gdb) detach
(gdb) quit

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

Выводы

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

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

#1 2018-05-05 07:25:18

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Problem with launching a programms after updating linux

Good day, all.
I met problem with launching half  programs after updating linux (last stable version for me  linux-4.16.2-2-x86_64):
example of stack trace for terminator:

(terminator:2512): dbind-WARNING **: 14:55:59.839: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

with firefox-developer-edition:

firefox-developer-deition:
ExceptionHandler::GenerateDump cloned child 2651
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

I downgrade to linux-4.16.2-2-x86_64 and all works ok, but what i should do to handle this problem with latest version of linux?

#2 2018-05-05 08:10:02

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,421
Website

Re: Problem with launching a programms after updating linux

Not an Arch discussion, moving to NC…


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

#3 2018-05-05 10:23:13

Skunky
Member
Registered: 2018-01-25
Posts: 229

Re: Problem with launching a programms after updating linux

Hello lgar_tigar, can you try reinstalling one of the programs not working after update?

#4 2018-05-05 10:29:39

loqs
Member
Registered: 2014-03-06
Posts: 16,500

Re: Problem with launching a programms after updating linux

Please post the kernel messages from the journal for a boot under the affected version also a backtrace from a coredump of one of the programs.

#5 2018-05-05 12:31:47

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

Skunky wrote:

Hello lgar_tigar, can you try reinstalling one of the programs not working after update?

Sure, it was 1st step when i got this issue. It didn’t help.

#6 2018-05-05 12:40:52

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 19,772

Re: Problem with launching a programms after updating linux

Please post complete outputs, what you posted so far are random excerpts that are almost certain to have no relation to what you are experiencing (especially the first one is quite likely to be normal even in a working setup)

https://bbs.archlinux.org/viewtopic.php?id=57855

Post a journal excerpt look for coredumps etc

Last edited by V1del (2018-05-05 12:43:34)

#7 2018-05-06 14:19:24

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

Try to provide all logs that can find =x

I updates linux to 4.16.6-1-ARCH GNU/Linux

during launching terminator:
just dmsg part:

[  947.735520] ata1.00: exception Emask 0x0 SAct 0x10000 SErr 0x50000 action 0x0
[  947.735533] ata1.00: irq_stat 0x40000008
[  947.735542] ata1: SError: { PHYRdyChg CommWake }
[  947.735550] ata1.00: failed command: READ FPDMA QUEUED
[  947.735569] ata1.00: cmd 60/08:80:a0:0b:24/00:00:1d:00:00/40 tag 16 ncq dma 4096 in
                        res 41/40:08:a0:0b:24/00:00:1d:00:00/6d Emask 0x409 (media error) <F>
[  947.735577] ata1.00: status: { DRDY ERR }
[  947.735583] ata1.00: error: { UNC }
[  947.735598] ata1: hard resetting link
[  948.050086] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  948.127333] ata1.00: configured for UDMA/100
[  948.127525] sd 0:0:0:0: [sda] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  948.127534] sd 0:0:0:0: [sda] tag#16 Sense Key : Medium Error [current] 
[  948.127541] sd 0:0:0:0: [sda] tag#16 Add. Sense: Unrecovered read error - auto reallocate failed
[  948.127549] sd 0:0:0:0: [sda] tag#16 CDB: Read(10) 28 00 1d 24 0b a0 00 00 08 00
[  948.127554] print_req_error: I/O error, dev sda, sector 488901536
[  948.127623] ata1: EH complete
[  952.168776] ata1.00: exception Emask 0x0 SAct 0x40 SErr 0x50000 action 0x0
[  952.168798] ata1.00: irq_stat 0x40000008
[  952.168807] ata1: SError: { PHYRdyChg CommWake }
[  952.168816] ata1.00: failed command: READ FPDMA QUEUED
[  952.168834] ata1.00: cmd 60/08:30:a0:0b:24/00:00:1d:00:00/40 tag 6 ncq dma 4096 in
                        res 41/40:08:a0:0b:24/00:00:1d:00:00/6d Emask 0x409 (media error) <F>
[  952.168843] ata1.00: status: { DRDY ERR }
[  952.168849] ata1.00: error: { UNC }
[  952.168863] ata1: hard resetting link
 

seems like problem with reading of failed HDD bloks but how it relate to launch some of programm (moreower i reinstall them).

console terminator launch output:

 (terminator:1333): dbind-WARNING **: 14:14:18.741: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Ошибка шины (стек памяти сброшен на диск)

coredumpctl relate to terminator:

Sun 2018-05-06 14:16:13 +03    1433  1002   100   7 present   /usr/lib/at-spi-bus-launcher

[nolik@R2D2 GetItFreeService]$ coredumpctl info 1433
           PID: 1433 (at-spi-bus-laun)
           UID: 1002 (nolik)
           GID: 100 (users)
        Signal: 7 (BUS)
     Timestamp: Sun 2018-05-06 14:16:08 +03 (2min 9s ago)
  Command Line: /usr/lib/at-spi-bus-launcher
    Executable: /usr/lib/at-spi-bus-launcher
 Control Group: /user.slice/user-1002.slice/user@1002.service/at-spi-dbus-bus.service
          Unit: user@1002.service
     User Unit: at-spi-dbus-bus.service
         Slice: user-1002.slice
     Owner UID: 1002 (nolik)
       Boot ID: 43399cbd171e4e0f806265ff2b524453
    Machine ID: 7722fbcff55c4d2ca3853b63790eac1f
      Hostname: R2D2
       Storage: /var/lib/systemd/coredump/core.at-spi-bus-laun.1002.43399cbd171e4e0f806265ff2b524453.1433.1525605368000000.lz4
       Message: Process 1433 (at-spi-bus-laun) of user 1002 dumped core.
                
                Stack trace of thread 1433:
                #0  0x00007f118bc3742a n/a (libdconfsettings.so)
                #1  0x00007f118bc3865e n/a (libdconfsettings.so)
                #2  0x00007f118bc37944 n/a (libdconfsettings.so)
                #3  0x00007f118bc38a19 n/a (libdconfsettings.so)
                #4  0x00007f118e262418 n/a (libgobject-2.0.so.0)
                #5  0x00007f118e264180 g_object_new_valist (libgobject-2.0.so.0)
                #6  0x00007f118e26450a g_object_new (libgobject-2.0.so.0)
                #7  0x00005579e81c4de0 n/a (at-spi-bus-launcher)
                #8  0x00007f118e8629a7 __libc_start_main (libc.so.6)
                #9  0x00005579e81c4e9a n/a (at-spi-bus-launcher)
 

#8 2018-05-06 14:30:14

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

with firefox-developer-edition:
console output:

 [nolik@R2D2 GetItFreeService]$ firefox-developer-edition 
ExceptionHandler::GenerateDump cloned child 1806ExceptionHandler::WaitForContinueSignal waiting for continue signal...

ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Ошибка шины (стек памяти сброшен на диск)
[nolik@R2D2 GetItFreeService]$ Failed to open curl lib from binary, use libcurl.so instead

!Sic in both examples we got Ошибка шины (стек памяти сброшен на диск) => it’s mean: Bus error (the memory stack is flushed to disk)

coredumpctl

PNS_12HelperThreadEEE5StartES2_ (libxul.so)
                #5  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #6  0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1750:
                #0  0x00007f1c97a84f09 syscall (libc.so.6)
                #1  0x00007f1c88bc065b epoll_wait (libxul.so)
                #2  0x00007f1c88bc2753 epoll_dispatch (libxul.so)
                #3  0x00007f1c88bc4f92 event_base_loop (libxul.so)
                #4  0x00007f1c88baca7e _ZN4base19MessagePumpLibevent3RunEPNS_11MessagePump8DelegateE (libxul.so)
                #5  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #6  0x00007f1c88bbaf2a _ZN4base6Thread10ThreadMainEv (libxul.so)
                #7  0x00007f1c88bac5ba _ZL10ThreadFuncPv (libxul.so)
                #8  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #9  0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1751:
                #0  0x00007f1c984fd3bb pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000055cf02b7d76e _ZN7mozilla6detail21ConditionVariableImpl8wait_forERNS0_9MutexImplERKNS_16BaseTimeDurationINS>
                #2  0x00007f1c88799fb7 _ZN11TimerThread3RunEv (libxul.so)
                #3  0x00007f1c88797c41 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #4  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #5  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #6  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #7  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #8  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #9  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #10 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1802:
                #0  0x00007f1c97a84f09 syscall (libc.so.6)
                #1  0x000055cf02b71bf9 _ZL9pages_mapPvm.constprop.110 (firefox)
                #2  0x000055cf02b74688 _ZL11chunk_allocmmbPb (firefox)
                #3  0x000055cf02b77c5e _ZN7arena_t8AllocRunEmbb (firefox)
                #4  0x000055cf02b795ed _ZN7arena_t16GetNonFullBinRunEP11arena_bin_t (firefox)
                #5  0x000055cf02b7a263 _ZN7arena_t6MallocEmb (firefox)
                #6  0x000055cf02b7a38e calloc (firefox)
                #7  0x00007f1c710ba364 n/a (libtasn1.so.6)
                #8  0x00007f1c710b7652 n/a (libtasn1.so.6)
                #9  0x00007f1c710b6bf4 asn1_der_decoding2 (libtasn1.so.6)
                #10 0x00007f1c710b6c48 asn1_der_decoding (libtasn1.so.6)
                #11 0x00007f1c712dd149 n/a (libnssckbi.so)
                #12 0x00007f1c712cd195 n/a (libnssckbi.so)
                #13 0x00007f1c712cdef1 n/a (libnssckbi.so)
                #14 0x00007f1c712ccb8d n/a (libnssckbi.so)
                #15 0x00007f1c712cfc16 n/a (libnssckbi.so)
                #16 0x00007f1c712d2568 n/a (libnssckbi.so)
                #17 0x00007f1c712d334a n/a (libnssckbi.so)
                #18 0x00007f1c712d3997 n/a (libnssckbi.so)
                #19 0x00007f1c712d3c89 n/a (libnssckbi.so)
                #20 0x00007f1c712db8b8 n/a (libnssckbi.so)
                #21 0x00007f1c712db9b6 n/a (libnssckbi.so)
                #22 0x00007f1c712dbb5a n/a (libnssckbi.so)
                #23 0x00007f1c712dc56c n/a (libnssckbi.so)
                #24 0x00007f1c712d7756 n/a (libnssckbi.so)
                #25 0x00007f1c987a3b82 pk11_FindObjectByTemplate (/usr/lib/firefox-developer-edition/libnss3.so)
                #26 0x00007f1c987b18ce PK11_InitSlot (/usr/lib/firefox-developer-edition/libnss3.so)
                #27 0x00007f1c98799965 secmod_LoadPKCS11Module (/usr/lib/firefox-developer-edition/libnss3.so)
                #28 0x00007f1c987a67a6 SECMOD_LoadModule (/usr/lib/firefox-developer-edition/libnss3.so)
                #29 0x00007f1c987a699a SECMOD_LoadUserModule (/usr/lib/firefox-developer-edition/libnss3.so)
                #30 0x00007f1c886f96ab _ZN7mozilla3psm17LoadLoadableRootsERK9nsTStringIcES4_ (libxul.so)
                #31 0x00007f1c8b5561b0 _ZN21LoadLoadableRootsTask17LoadLoadableRootsEv (libxul.so)
                #32 0x00007f1c8b5565bc _ZN21LoadLoadableRootsTask3RunEv (libxul.so)
                #33 0x00007f1c88797c41 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #34 0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #35 0x00007f1c88bd9f7a _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #36 0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #37 0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #38 0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #39 0x00007f1c984f70bc start_thread (libpthread.so.0)
                #40 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1795:
                #0  0x00007f1c984fd07c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000055cf02b7d548 _ZN7mozilla6detail21ConditionVariableImpl4waitERNS0_9MutexImplE (firefox)
                #2  0x00007f1c889f4383 _ZN7mozilla3net13CacheIOThread10ThreadFuncEv (libxul.so)
                #3  0x00007f1c889f440f _ZN7mozilla3net13CacheIOThread10ThreadFuncEPv (libxul.so)
                #4  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #5  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #6  0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1753:
                #0  0x00007f1c97a7fcd9 __poll (libc.so.6)
                #1  0x00007f1c988e7b02 _pr_poll_with_poll (/usr/lib/firefox-developer-edition/libnspr4.so)
                #2  0x00007f1c888488b6 _ZN7mozilla3net24nsSocketTransportService4PollEPNS_16BaseTimeDurationINS_27TimeDurationValueC>
                #3  0x00007f1c888524d5 _ZN7mozilla3net24nsSocketTransportService15DoPollIterationEPNS_16BaseTimeDurationINS_27TimeDu>
                #4  0x00007f1c888528ac _ZN7mozilla3net24nsSocketTransportService3RunEv (libxul.so)
                #5  0x00007f1c88797c41 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #6  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #7  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #8  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #9  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #10 0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #11 0x00007f1c984f70bc start_thread (libpthread.so.0)
                #12 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1796:
                #0  0x00007f1c984fd07c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000055cf02b7d548 _ZN7mozilla6detail21ConditionVariableImpl4waitERNS0_9MutexImplE (firefox)
                #2  0x00007f1c8879064b _ZN7mozilla16ThreadEventQueueINS_10EventQueueEE8GetEventEbPNS_13EventPriorityE (libxul.so)
                #3  0x00007f1c88797bc9 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #4  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #5  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #6  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #7  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #8  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #9  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #10 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1793:
                #0  0x00007f1c984fd07c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000055cf02b7d548 _ZN7mozilla6detail21ConditionVariableImpl4waitERNS0_9MutexImplE (firefox)
                #2  0x00007f1c8879064b _ZN7mozilla16ThreadEventQueueINS_10EventQueueEE8GetEventEbPNS_13EventPriorityE (libxul.so)
                #3  0x00007f1c88797bc9 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #4  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #5  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #6  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #7  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #8  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #9  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #10 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1794:
                #0  0x00007f1c984fd3bb pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000055cf02b7d76e _ZN7mozilla6detail21ConditionVariableImpl8wait_forERNS0_9MutexImplERKNS_16BaseTimeDurationINS>
                #2  0x00007f1c8879e52a _ZN12nsThreadPool3RunEv (libxul.so)
                #3  0x00007f1c88797c41 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #4  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #5  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #6  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #7  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #8  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #9  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #10 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1788:
                #0  0x00007f1c984fd07c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000055cf02b7d548 _ZN7mozilla6detail21ConditionVariableImpl4waitERNS0_9MutexImplE (firefox)
                #2  0x00007f1c8879064b _ZN7mozilla16ThreadEventQueueINS_10EventQueueEE8GetEventEbPNS_13EventPriorityE (libxul.so)
                #3  0x00007f1c88797bc9 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #4  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #5  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #6  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #7  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #8  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #9  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #10 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1797:
                #0  0x00007f1c984fd07c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000055cf02b7d548 _ZN7mozilla6detail21ConditionVariableImpl4waitERNS0_9MutexImplE (firefox)
                #2  0x00007f1c8879064b _ZN7mozilla16ThreadEventQueueINS_10EventQueueEE8GetEventEbPNS_13EventPriorityE (libxul.so)
                #3  0x00007f1c88797bc9 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #4  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #5  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #6  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #7  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #8  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #9  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #10 0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1752:
                #0  0x00007f1c97a7fcd9 __poll (libc.so.6)
                #1  0x00007f1c88b3637f _ZN20nsNotifyAddrListener3RunEv (libxul.so)
                #2  0x00007f1c88797c41 _ZN8nsThread16ProcessNextEventEbPb.part.257 (libxul.so)
                #3  0x00007f1c8879e958 _Z19NS_ProcessNextEventP9nsIThreadb (libxul.so)
                #4  0x00007f1c88bd9fba _ZN7mozilla3ipc28MessagePumpForNonMainThreads3RunEPN4base11MessagePump8DelegateE (libxul.so)
                #5  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #6  0x00007f1c88795b37 _ZN8nsThread10ThreadFuncEPv (libxul.so)
                #7  0x00007f1c988ecfc3 _pt_root (/usr/lib/firefox-developer-edition/libnspr4.so)
                #8  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #9  0x00007f1c97a8a2ff __clone (libc.so.6)
                
                Stack trace of thread 1785:
                #0  0x00007f1c984fd07c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007f1c88bba1d0 _ZN4base13WaitableEvent9TimedWaitERKNS_9TimeDeltaE (libxul.so)
                #2  0x00007f1c88bba204 _ZN4base13WaitableEvent4WaitEv (libxul.so)
                #3  0x00007f1c88bad628 _ZN4base18MessagePumpDefault3RunEPNS_11MessagePump8DelegateE (libxul.so)
                #4  0x00007f1c88baf150 _ZN11MessageLoop3RunEv (libxul.so)
                #5  0x00007f1c88bbaf2a _ZN4base6Thread10ThreadMainEv (libxul.so)
                #6  0x00007f1c88bac5ba _ZL10ThreadFuncPv (libxul.so)
                #7  0x00007f1c984f70bc start_thread (libpthread.so.0)
                #8  0x00007f1c97a8a2ff __clone (libc.so.6)

#9 2018-05-06 14:54:53

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 19,772

Re: Problem with launching a programms after updating linux

If your harddisk is starting to fail this will have all sorts of wide reaching correlations. Back up what you can immediately. Run a SMART test and post the -a results after the mentioned time elapses.

But I don’t have much hope of that coming out positive

#10 2018-05-06 15:01:19

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

V1del wrote:

If your harddisk is starting to fail this will have all sorts of wide reaching correlations. Back up what you can immediately. Run a SMART test and post the -a results after the mentioned time elapses.

But I don’t have much hope of that coming out positive

But how it relate to the fact that  all works ok if i will downgrade my linux version to 4.16.2-2-ARCH?

Last edited by Igar_tigar (2018-05-06 15:01:40)

#11 2018-05-06 15:39:48

loqs
Member
Registered: 2014-03-06
Posts: 16,500

Re: Problem with launching a programms after updating linux

Can you determine which kernel the issue started with between 4.16.2-2 and 4.16.6-1?  You can obtain kernel versions you do not have cached from the ALA.
Running a SMART test / checking the SMART status of devices will rule out a possibility.

#12 2018-05-06 15:47:34

seth
Member
Registered: 2012-09-03
Posts: 42,636

Re: Problem with launching a programms after updating linux

It might be an unrelated problem, or a kernel bug or the newer kernel triggers some bad sectors.

In any case: YOU WANT TO BE SURE YOUR HDD IS OK and the stackpile of SIGBUS’ plus the IO errors should scare the shit out of you.

Once you settled it’s NOT the HDD, it’s time to check on whether this might relate to drive power management, swap handling, a single bad block (does dmesg always point the same problematic sector?), …

#13 2018-05-06 17:17:37

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

loqs wrote:

Can you determine which kernel the issue started with between 4.16.2-2 and 4.16.6-1?  You can obtain kernel versions you do not have cached from the ALA.
Running a SMART test / checking the SMART status of devices will rule out a possibility.

issue started from linux-4.16.3-1-x86_64.pkg.

later i will provide SMART test results (but idea that system depend on some HDD block on new version little bit confuse me).

#14 2018-05-06 18:44:16

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

Smart results (Too much info for me sad )

 smartctl -a /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.16.2-2-ARCH] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Toshiba 2.5" HDD MK..75GSX
Device Model:     TOSHIBA MK5075GSX
Serial Number:    81MRD284B
LU WWN Device Id: 5 000039 37b289f9b
Firmware Version: GT001M
User Capacity:    500107862016 bytes [500 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    5400 rpm
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Sun May  6 18:43:22 2018 +03
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00)	Offline data collection activity
					was never started.
					Auto Offline Data Collection: Disabled.
Self-test execution status:      ( 112)	The previous self-test completed having
					the read element of the test failed.
Total time to complete Offline 
data collection: 		(  120) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 163) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   050    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       2013
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       8938
  5 Reallocated_Sector_Ct   0x0033   061   061   050    Pre-fail  Always       -       15400
  7 Seek_Error_Rate         0x000b   100   100   050    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   050    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   049   049   000    Old_age   Always       -       20771
 10 Spin_Retry_Count        0x0033   253   100   030    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       8802
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       277
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       441
193 Load_Cycle_Count        0x0032   075   075   000    Old_age   Always       -       255166
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       37 (Min/Max 13/65)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1028
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       976
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       8256
222 Loaded_Hours            0x0032   061   061   000    Old_age   Always       -       15728
223 Load_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
224 Load_Friction           0x0022   100   100   000    Old_age   Always       -       0
226 Load-in_Time            0x0026   100   100   000    Old_age   Always       -       311
240 Head_Flying_Hours       0x0001   100   100   001    Pre-fail  Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 20799 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 20799 occurred at disk power-on lifetime: 20771 hours (865 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 5a a0 0b 24 6d  Error: WP at LBA = 0x0d240ba0 = 220466080

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 08 60 78 81 45 40 00      01:55:26.546  WRITE FPDMA QUEUED
  60 10 58 a0 0b 24 40 00      01:55:23.756  READ FPDMA QUEUED
  60 88 50 08 44 22 40 00      01:55:23.756  READ FPDMA QUEUED
  60 20 48 98 40 22 40 00      01:55:23.741  READ FPDMA QUEUED
  60 e0 40 50 8c 08 40 00      01:55:23.734  READ FPDMA QUEUED

Error 20798 occurred at disk power-on lifetime: 20769 hours (865 days + 9 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 ca a0 0b 24 6d  Error: UNC at LBA = 0x0d240ba0 = 220466080

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 e0 58 0d 44 40 00      00:00:48.071  READ FPDMA QUEUED
  60 18 d8 68 0a 29 40 00      00:00:48.071  READ FPDMA QUEUED
  61 40 d0 98 08 84 40 00      00:00:48.071  WRITE FPDMA QUEUED
  60 10 c8 a0 0b 24 40 00      00:00:46.581  READ FPDMA QUEUED
  60 08 c0 98 0b c1 40 00      00:00:46.562  READ FPDMA QUEUED

Error 20797 occurred at disk power-on lifetime: 20769 hours (865 days + 9 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 92 18 1f 24 6d  Error: WP at LBA = 0x0d241f18 = 220471064

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 00 98 00 b8 57 40 00      06:59:09.700  WRITE FPDMA QUEUED
  60 08 90 18 1f 24 40 00      06:59:09.556  READ FPDMA QUEUED
  60 08 88 60 0c c1 40 00      06:59:09.540  READ FPDMA QUEUED
  61 78 80 38 2a 84 40 00      06:59:09.538  WRITE FPDMA QUEUED
  61 00 78 00 b2 57 40 00      06:59:08.632  WRITE FPDMA QUEUED

Error 20796 occurred at disk power-on lifetime: 20768 hours (865 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 12 a0 0b 24 6d  Error: WP at LBA = 0x0d240ba0 = 220466080

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 38 18 98 08 84 40 00      06:52:05.822  WRITE FPDMA QUEUED
  60 10 10 a0 0b 24 40 00      06:52:05.318  READ FPDMA QUEUED
  60 20 08 00 48 93 40 00      06:52:05.318  READ FPDMA QUEUED
  60 08 00 98 0b c1 40 00      06:52:05.299  READ FPDMA QUEUED
  60 30 f0 90 0e c8 40 00      06:52:05.298  READ FPDMA QUEUED

Error 20795 occurred at disk power-on lifetime: 20768 hours (865 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 41 5a a0 0b 24 6d  Error: WP at LBA = 0x0d240ba0 = 220466080

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 08 60 b0 43 f3 40 00      06:39:53.717  WRITE FPDMA QUEUED
  60 08 58 a0 0b 24 40 00      06:39:53.717  READ FPDMA QUEUED
  60 00 50 30 f8 88 40 00      06:39:53.717  READ FPDMA QUEUED
  61 f8 48 80 83 84 40 00      06:39:53.717  WRITE FPDMA QUEUED
  61 08 40 00 0a 55 40 00      06:39:53.717  WRITE FPDMA QUEUED

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       00%     20770         488296080
# 2  Short offline       Completed without error       00%         1         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

#15 2018-05-06 18:48:41

loqs
Member
Registered: 2014-03-06
Posts: 16,500

Re: Problem with launching a programms after updating linux

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       00%     20770         488296080

The drive appears to have issues independent of any kernel issue.
Edit:
From 4.16.3 Release Notes

commit 80dc97f7e1e1b90ab62dc120ec9d09d69c8e03e8
Author: Bart Van Assche <bart.vanassche@wdc.com>
Date:   Thu Apr 5 10:32:59 2018 -0700

    Revert "scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"
    
    commit cbe095e2b584623b882ebaf6c18e0b9077baa3f7 upstream.
    
    The description of commit e39a97353e53 is wrong: it mentions that commit
    2a842acab109 introduced a bug in __scsi_error_from_host_byte() although that
    commit did not change the behavior of that function.  Additionally, commit
    e39a97353e53 introduced a bug: it causes commands that fail with
    hostbyte=DID_OK and driverbyte=DRIVER_SENSE to be completed with
    BLK_STS_OK. Hence revert that commit.
    
    Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()")
    Reported-by: Damien Le Moal <damien.lemoal@wdc.com>
    Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Douglas Gilbert <dgilbert@interlog.com>
    Cc: Damien Le Moal <damien.lemoal@wdc.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Lee Duncan <lduncan@suse.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Could explain why you were not seeing errors before 4.16.3

Last edited by loqs (2018-05-06 19:00:04)

#16 2018-05-06 18:51:30

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

loqs wrote:

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       00%     20770         488296080

The drive appears to have issues independent of any kernel issue.

suppose, yes, but now all works fine ¯\_(ツ)_/¯ despite of drive issue.

#17 2018-05-06 18:53:38

seth
Member
Registered: 2012-09-03
Posts: 42,636

Re: Problem with launching a programms after updating linux

  5 Reallocated_Sector_Ct   0x0033   061   061   050    Pre-fail  Always       -       15400
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       1028
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       976
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       00%     20770         488296080

Before anything else, save all valuable data from that disk.
The get a life-disk system w/ maintainance focus (eg. grml) and run https://wiki.archlinux.org/index.php/Badblocks (you can go w/ the non-destructive test) to see whether this is an isolated error or the disk is toast.
Then you’ll have to make up your mind about the further fate of the disk, but I would cease to «trust» it (though it might still be good as temporary media tank attached to your TV or so)

#18 2018-05-07 14:46:47

ua4000
Member
Registered: 2015-10-14
Posts: 329

Re: Problem with launching a programms after updating linux

220 Disk_Shift              0x0002   100   100   000    Old_age   Always       -       8256

Never seen before, had to google:
«Distance of the disk has shifted relative to the spindle. Incorrect disk spin can be cause by mechanical shock or high temperature.»

#19 2018-06-12 18:37:15

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

issue, don’t relate to hard disk. I suppose it’s relate to dbus.

all time this dbus issue start after update with linux version >4.16.2-2.

although got a dbus error on Geany.

#20 2018-06-12 19:16:20

seth
Member
Registered: 2012-09-03
Posts: 42,636

Re: Problem with launching a programms after updating linux

DBUS is not related to the kernel, does not cause IO errors in dmesg and that disc is not reported as healthy by any stretch.
You’re free to believe whatever you want, but the most likely explanation is that the inodes that hold some dbus binary or library are affected by the disc damage.

#21 2018-06-12 20:07:49

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

seth wrote:

DBUS is not related to the kernel, does not cause IO errors in dmesg and that disc is not reported as healthy by any stretch.
You’re free to believe whatever you want, but the most likely explanation is that the inodes that hold some dbus binary or library are affected by the disc damage.

sure, i agree that my disc has a crashed blocks. But how it’s explain that when i reverting to any linux package 4.16.2-2 or early, i didn’t get any errors (related to Dbus) and problems with launch some of programs?

#22 2018-06-12 22:16:30

seth
Member
Registered: 2012-09-03
Posts: 42,636

Re: Problem with launching a programms after updating linux

Comment #15 suggested that there’s been a bug in 4.16 that stashed I/O failures. With those failures being reported again w/ 4.16.3, you face coredumps rather than silent failures in the HW.

How does the LTS kernel behave?
What about some 4.15 kernel?

#23 2018-06-14 19:14:04

Igar_tigar
Member
Registered: 2018-02-18
Posts: 17

Re: Problem with launching a programms after updating linux

seth wrote:

Comment #15 suggested that there’s been a bug in 4.16 that stashed I/O failures. With those failures being reported again w/ 4.16.3, you face coredumps rather than silent failures in the HW.

How does the LTS kernel behave?
What about some 4.15 kernel?

Possible u right.

I met same issue when installed linux-lts and 4.15-1.

Понравилась статья? Поделить с друзьями:
  • Ошибка чтения жесткого диска что делать
  • Ошибка шаблонов документов атол 55ф
  • Ошибка шаблонов документов атол 22 птк
  • Ошибка шаблонов документов атол 150ф
  • Ошибка шаблонов документов sigma 10