LINUX.ORG.RU

Aborted (core dumped)

 ,


2

3
user@localhost ~/freecad/experiment_0000 $ freecad
FreeCAD 0.19, Libs: 0.19RUnknown
© Juergen Riegel, Werner Mayer, Yorik van Havre and others 2001-2021
FreeCAD is free and open-source software licensed under the terms of LGPL2+ license.
FreeCAD wouldn't be possible without FreeCAD community.
  #####                 ####  ###   ####  
  #                    #      # #   #   # 
  #     ##  #### ####  #     #   #  #   # 
  ####  # # #  # #  #  #     #####  #   # 
  #     #   #### ####  #    #     # #   # 
  #     #   #    #     #    #     # #   #  ##  ##  ##
  #     #   #### ####   ### #     # ####   ##  ##  ##

Aborted (core dumped)

У меня вопрос: какая часть системы выводит сообщение

Aborted (core dumped)

Делает ли это ядро?
Или это рантайм библиотека языка Си (glibc) или кто-то ещё?

Я бы хотел высказать авторам этого куска кода всё что я думаю об информативности данного сообщения.

Мне не ясно:
- в какой файл записан дамп
- что вообще обычно делают с дампами (нет гиперссылки на туториал)
- что делают с дампами в этом приложении (нет гиперссылки на форум или багтрекер)
- какие причины могли привести к такой ситуации в принципе, и какая из них кажется более вероятной.

На дворе век нейросетей, которые сами думают, а тут простую диагностику не смогли сами выполнить.

А уже не говорю о том, чтобы предложить действия по исправлению ситуации.

Или вот эти чуваки в строчках про копирайт, им сложно было вписать свои email-адреса, каналы в телеграме для поддержки, или что там вообще у них принято для связи? Как эту коммьюнити найти.

★★★

Последнее исправление: Shushundr (всего исправлений: 1)

исходя из вот этой темы я так понял, что ядро принимает участие, и ещё какой-то стандартный обработчик сигналов (где он находится?)

«в 2.6 можно изменить политику именования core файлов: /proc/sys/kernel/core_pattern. напишите туда, к примеру «core.%p», и у вас будет суффикс из pid'а процесса»

$ cat /proc/sys/kernel/core_pattern
|/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

Мне не ясно, зачем тут вертикальная чёрточка в начале строки.

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 2)
Ответ на: комментарий от Shushundr

Прочитал статью
https://www.baeldung.com/linux/managing-core-dumps

$ ulimit -c
unlimited

Про чёрточку там тоже написано (но как-то невнятно всё-таки, ну кто так статьи пишет? Показали бы где она в ядре обрабатывается.).

/var/lib/systemd/coredump/

$ sudo ls -1 /var/lib/systemd/coredump/
core.freecad.1000.d22dcfa5a7bb4e0389df9ca3b4263a9b.3214101.1654486293000000.zst
core.freecad.1000.d22dcfa5a7bb4e0389df9ca3b4263a9b.3224483.1654489724000000.zst

Ну ок, где лежат - выяснили.

$ coredumpctl debug 3224483 PID: 3224483 (freecad) UID: 1000 (user) GID: 1000 (user) Signal: 6 (ABRT) Timestamp: Mon 2022-06-06 07:28:44 MSK (4h 3min ago) Command Line: freecad Executable: /usr/lib64/freecad/bin/FreeCAD Control Group: /user.slice/user-1000.slice/session-1.scope Unit: session-1.scope Slice: user-1000.slice Session: 1 Owner UID: 1000 (user) Boot ID: d22dcfa5a7bb4e0389df9ca3b4263a9b Machine ID: 53393efbc533ed79b248f18a5e6ab0e4 Hostname: lacaille9352 Storage: /var/lib/systemd/coredump/core.freecad.1000.d22dcfa5a7bb4e0389df9ca3b4263a9b.3224483.1654489724000000.zst (present) Disk Size: 2.3M Message: Process 3224483 (freecad) of user 1000 dumped core.

GNU gdb (Gentoo 10.1 vanilla) 10.1 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type «show copying» and «show warranty» for details. This GDB was configured as «x86_64-pc-linux-gnu». Type «show configuration» for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>.

For help, type «help». Type «apropos word» to search for commands related to «word»... Reading symbols from /usr/lib64/freecad/bin/FreeCAD... (No debugging symbols found in /usr/lib64/freecad/bin/FreeCAD)

warning: core file may not match specified executable file. [New LWP 3224483] [New LWP 3224484] [Thread debugging using libthread_db enabled] Using host libthread_db library «/lib64/libthread_db.so.1». Core was generated by `freecad'. Program terminated with signal SIGABRT, Aborted. #0 0x00007efc0632842c in ?? () from /lib64/libc.so.6 [Current thread is 1 (Thread 0x7efc004d2080 (LWP 3224483))] (gdb)

И чего дальше?

Shushundr ★★★
() автор топика
Ответ на: комментарий от goingUp

Программисты в опенсорсе занимаются только тем, что им интересно.
Ну скажут они «умвр», и что?

Ещё и поругают, что засираю им багтрекер.
После чего сделают новую версию и позакрывают все баги старой версии с решением «устарело».

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от Shushundr

и что?

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

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от Shushundr

Дальше ты с помощью gdb изучаешь состояние, в которое пришло приложение, и пытаешься вывести, каким образом оно к нему пришло.

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

Gary ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Почему только этот пакет, а не все его зависимости?

Как получить полный стектрейс не разрешая USE=«debug» глобально (потому что это плохо для безопасности, и пересобирать всю систему дольше, чем нужную часть)?

Что надо делать для того, чтобы установить два инстанса freecad рядом - один релизный, другой дебужный?

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 2)
Ответ на: комментарий от Shushundr

Клонируешь сорцы, раскатываешь докер-образ https://github.com/FreeCAD/FreeCAD/blob/master/ci/Dockerfile, либо ставишь руками всё что надо, компилируешь, запускаешь из билд-директории.

fluorite ★★★★★
()

atrus, кстати, я нашел ответ на твой вопрос. Он на той же странице изложен - https://www.baeldung.com/linux/managing-core-dumps.

Надо передавать из ядра (конфигурируется при помощи kernel.core_pattern) в скрипт имя процесса, а в скрипте имя процесса проверять:

#!/usr/bin/python
# Filename: /tmp/core_dump_example.py
import sys

# Expect sys.argv to have %e configured in kernel.core_pattern
process_filename = sys.argv[1]

if process_filename == "sleep":
    with open("/tmp/sleep_core_dump", "wb") as core_dump:
        core_contents = bytearray(sys.stdin.read())
        core_dump.write(core_contents)

В тот топик я написать не могу, потому что он заблокирован, поэтому пишу здесь.
Надеюсь, что этот ответ тебе поможет, пусть и спустя 15 лет. Лучше поздно, чем никогда.

Shushundr ★★★
() автор топика
Ответ на: комментарий от fluorite

Докер, это разве не для серверных проектов? Будут ли два приложения - одно из докера релизное и одно с машины дебужное работать вместе на одном XOrg-сервере?

Shushundr ★★★
() автор топика

какая часть системы выводит сообщение

Командная оболочка. Скорее всего, у тебя bash.

Делает ли это ядро?

Нет.

Или это рантайм библиотека языка Си (glibc)

Нет.

или кто-то ещё?

Что-то ещё.

Или вот эти чуваки в строчках про копирайт, им сложно было вписать свои email-адреса, каналы в телеграме для поддержки, или что там вообще у них принято для связи?

Было сложно.

Как эту коммьюнити найти.

Пояндексить. Если не нравится яндексить в яндексе, можно яндексить в гугле.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

какая часть системы выводит сообщение

Командная оболочка. Скорее всего, у тебя bash.

Да, у меня bash. Но почему такой странное умозаключение, что сообщение печатает она? Мне кажется, что эта строчка находится где-то в systemd.

Сначала bash запускает процесс.

Процесс как-то наворачивается, и ему ядро высылает сигнал, что всё пошло́ не так.

Процесс не обрабатывает сигнал, и за обработку берётся стандартный обработчик.

Где находится этот стандартный обработчик? В ядре? В рантайм-библиотеке?

Так или иначе, управление попадает в ядро (правда непонятно, происходит ли это до или после завершения процесса).

Ядро запускает программу, прописанную в той конфигурационной переменной и передаёт на её stdin поток с дампом.

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

Затем управление возвращается в ядро. Ядро завершает процесс (раньше оно процесс завершить могло бы, но мало ли, вдруг там ещё отладчик кто-то захочет прицепить? Поэтому, скорее всего, процесс всё это время находится в остановленном состоянии.

Затем ядро возвращает управление в bash. Bash бы мог бы конечно написать, что «core dumped», но он не обладает этой информацией!!! Откуда ему знать, какое именно решение по обработке дампа приняла утилита из состава systemd?

Shushundr ★★★
() автор топика
Ответ на: комментарий от i-rinat

Во-первых, я никогда не смотрел на то, как устроено ядро (и не хочу).
Во-вторых, я не понимаю, как работают сигналы (это, вероятно что-то из POSIX и надо читать стандарт). Мне сам замысел непонятен - зачем надо было создавать такой механизм. Тем более, что есть dbus.
В третьих, мне неясно, каким образом дамп получается в формате ELF, если исходно память процесса является просто массивом байтов. А ведь ELF - это что-то с сегментами.
В четвёртых, я погрепал репозиторий bash на слова «core dumped» и там их не содержится. Ещё я пробовал запускать из-под /bin/sh, текст сообщения не изменился. Таким образом ты не мог определить какой командный процессор используется по этой строке.

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от Shushundr

зачем надо было создавать такой механизм. Тем более, что есть dbus

Действительно, зачем было изобретать каменный топор, когда есть Строймастер, где есть инструменты на любой вкус?

gremlin_the_red ★★★★★
()

Учитывая, что оказывается процессов-то много, мне стало ещё более непонятно, что именно дампится в процессе core dump. Вся группа процессов? Или общее адресное пространство всех нитей группы? Или есть как-то возможность узнать, что относится именно к этой нити (сомнительно)...

Shushundr ★★★
() автор топика
Ответ на: комментарий от Shushundr

А сигналы из ядра не выкинули.

Как подитожил мудрой человек,

предлагали нормальный IPC в ядро запилить чтобы не было необходимости в подобных костылях. Но нет, у Линуса случилась очередная истерика, в итоге воз и ныне там.

А вне ядра для таких вещей, понятное дело, не катит.

token_polyak ★★★★
()
Последнее исправление: token_polyak (всего исправлений: 1)
Ответ на: комментарий от Shushundr

никогда не смотрел
и не хочу
не понимаю
и не хочу
мне неясно
и не хочу

И зачем тогда?

я погрепал репозиторий bash на слова «core dumped» и там их не содержится

Хм. Самому погрепать, что ли…

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Поиск меня подвёл:
http://git.savannah.gnu.org/cgit/bash.git/log/?qt=grep&q=core+dumped

/var/db/repos/gentoo/app-shells/bash # ebuild bash-5.1_p16.ebuild prepare
...
>>> Preparing source in /var/tmp/portage/app-shells/bash-5.1_p16/work/bash-5.1
...
/var/tmp/portage/app-shells/bash-5.1_p16/work/bash-5.1 # grep -R -n "core dumped"
jobs.c:2001:		fprintf (stream, _("(core dumped) "));
jobs.c:4336:			fprintf (stderr, _(" (core dumped)"));
nojobs.c:921:	fprintf (stderr, _(" (core dumped)"));
/var/tmp/portage/app-shells/bash-5.1_p16/work/bash-5.1 #

http://git.savannah.gnu.org/cgit/bash.git/tree/jobs.c#n2001
http://git.savannah.gnu.org/cgit/bash.git/tree/jobs.c#n4336

Надо было github-ом искать:
https://github.com/gitGNU/gnu_bash/search?l=C&q=core dumped

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Итого осталось два принципиально непонятных мне вопроса:

  1. как вообще работает ядро. Это нужно знать для того, чтобы понимать, что происходит, когда часть процессора APIC (EAPIC или как там её) одного ядра принимает вызов от соответствующей части другого ядра и начинает обработку прерывания «межпроцессный вызов» Текущая работающая нить сохраняет свои регистры в свой стек, и дальше я не понимаю, что происходит. Ядро находится в этом же адресном пространстве или нет? Допустим, что новые значения регистров загружаются из разных там таблиц для прерываний, и адресное пространство у ядра своё. Как оно знает, какая нить была прервана? Или стек при этом сохраняется?

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

Shushundr ★★★
() автор топика
Последнее исправление: Shushundr (всего исправлений: 1)
Ответ на: комментарий от Shushundr

https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch10.html
«Linux kernel generally handles interrupts on the first CPU as a way of maximizing cache locality»

«fast interrupts (those that were requested with the SA_INTERRUPT flag) are executed with all other interrupts disabled on the current processor»

«A handler can’t transfer data to or from user space, because it doesn’t execute in the context of a process»

«handlers cannot call schedule»

Shushundr ★★★
() автор топика
Ответ на: комментарий от Shushundr

как вообще работает ядро

У него внутри неонка.

адресное пространство у ядра своё

Может быть совсем отдельное, может быть спроецировано в адресное пространство процесса.

Или стек при этом сохраняется?

Стек не нужно отдельно сохранять. Меняется только регистр-указатель на текущий стек.

Как и главное зачем формируется ELF-файл

А как ещё сохранять дамп?

или там есть что-то ещё, что надо знать?

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

ядро ... может быть спроецировано в адресное пространство процесса.

А зачем?
https://russianblogs.com/article/46791027919/
Это нужно только для загрузки кода процесса с накопителей при помощи модулей ядра, или для чего-то ещё? Допустим, что для этого программируется контроллер памяти (DMA), но он вроде отдельное устройство и для его программирования не надо память видеть (нужны только порты процессора). Ещё неясно, как оперативная память передаётся на карты (видеокарту и сетевую).

даже и это само умение тривиально.

Да, я видел. Выше по топику есть результат выполнения команды coredumpctl debug $PID, который показывает, что gdb успешно загрузил дамп.

пытаешься лезть в детали реализации, но при этом не хочешь

да, всё очень верно написано, особенно в части нежелания лезть и ненависти к программистам

Зачем?

Хочу чтобы freecad начал запускаться

Shushundr ★★★
() автор топика
Ответ на: комментарий от Shushundr

А зачем?

Для скорости.

Ещё неясно, как оперативная память передаётся на карты (видеокарту и сетевую).

Окей.

Хочу чтобы freecad начал запускаться

Ну и как считаешь, эти твои метания приближают тебя к цели?

i-rinat ★★★★★
()
Ответ на: комментарий от Shushundr

Неубедительно.

Подписывайтесь! Ставьте лайки! И жмите на колокольчик! В этом видео я расскажу вам, зачем ядро проецирует себя в адресное пространство процесса и почему такое бывает не всегда! Не забывайте подписываться, ставить лайки и жать на колокольчик! А пока вы подписываетесь, я расскажу вам о спонсоре сегодняшнего видео. Спонсор сегодняшнего видео — рейд шедоу ледженжс! Если вам понравилось сегодняшнее видео, ставьте лайки, подписывайтесь на канал! Итак, почему же ядро проецирует себя в адресное пространство процесса? Вы не поверите, насколько всё оказывается просто! Оно это делает для скорости! И-и-и ставьте лайки, подписывайтесь на канал. В следующем видео я расскажу зачем ядро иногда так не делает, и кому это выгодно. Подписывайтесь на канал, чтобы не пропустить новое видео. Всем пока!

Так убедительнее, да?

i-rinat ★★★★★
()
Ответ на: комментарий от Shushundr

Где находится этот стандартный обработчик? В ядре? В рантайм-библиотеке?

В ядре, поведение стандартных обработчиков описано в SIGNAL(7).

непонятно, происходит ли это до или после завершения процесса

До. У user mode helper’а есть возможность подключиться к памяти процесса для проведения дополнительного анализа. И память процесса, и pid на этот момент ещё существуют, но процесс уже начал разрушаться.

Bash бы мог бы конечно написать, что «core dumped», но он не обладает этой информацией!!! Откуда ему знать, какое именно решение по обработке дампа приняла утилита из состава systemd?

bash при запуске программы создаёт дочерний процесс, который делает execve на запускаемую программу. Его основной процесс в это время делает wait(2) на дочерний процесс и ждёт изменения его состояния. Значение, получаемое из wait(2), рассказывает bash, по какой причине системный вызов wait(2) вернул управление bash - например из-за того, что процесс завершился по сигналу SIGSEGV или SIGABRT.

bash не знает, какое именно действие совершила утилита из состава systemd. Сообщение «core dumped» печатается, если процесс завершился по сигналу, обработчик по-умолчанию для которого откладывает корку, и текущие лимиты позволяют это сделать (RLIMIT_CORE больше 0).

ак работают сигналы … зачем надо было создавать такой механизм

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

Например, программа могла в бесконечном цикле ожидать пользовательского ввода с терминала, даже когда терминал оказывался отключён. Поэтому появился SIGHUP, обработчик которого по-умолчанию просто убивает процесс, не давая ему зря прожигать ценное машинное время.

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

В современных (особенно многопоточных) программах прямого использования обработчиков сигналов лучше избегать, используя вместо них цикл обработки событий и signalfd.

исходно память процесса является просто массивом байтов

Набором массивов байт с разными атрибутами. См. /proc/self/maps.

каким образом дамп получается в формате ELF

Ядро его в таком виде пишет, если включена опция CONFIG_ELF_CORE.

kmeaw ★★★
()
Ответ на: комментарий от kmeaw

bash не знает
...
сообщение «core dumped» печатает

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

В военное время за такое - расстрел, а сейчас как раз спецоперация.

Shushundr ★★★
() автор топика