AkhИнтересует linux.

Если происходит критическая ошибка, то приложение вываливается с Killed. Как можно узнать из-за какого pid это произошло. Опции компиляци? Средства?

Посмотрите man ptrace, wait, waitpid .

По контексту вопроса не ясно , что используестя fork или pthread_create.

ptrace должен помочь, но не благодарное это дело писать свой дебагер.

Akh onstat- AkhИнтересует linux.

Если происходит критическая ошибка, то приложение вываливается с Killed. Как можно узнать из-за какого pid это произошло. Опции компиляци? Средства?

Посмотрите man ptrace, wait, waitpid .

По контексту вопроса не ясно , что используестя fork или pthread_create.

ptrace должен помочь, но не благодарное это дело писать свой дебагер.

pthread_create

Вот именно, что свой дебагер не благодарное дело писать.

Я не пойму, почему когда приложение убивается не пишется причина, или хотябы источник причины (pid из за которого произошла смерть). Может как-то это можно "включить"?

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

Akh onstat-GDB должен строчку говорить где это произошло.
Ну а дальше по обстоятельствам.

Он нормально тянет много-(в районе десятка)-потоковое приложение?

Если чесно, не знаю.

A. Fig Lee AkhСобсна, прошу по теме, без под%%%ок, если я правельно понял Афигли.

если смотреть core - где там потоки? Ето мемори и стек дамп. Потоки когда живую программу дебагишь.

Hint: Некоторое количество стеков( по количеству нитей на момент падения).

Akh ! AkhА какой менеджер потоки/процессы убивает?

ядро.

man kill
man signal

Пошутил что ли? Ясное дело, что не mc.

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

Так постоновка понятна?

Процесс родитель ловит сигнал SIGCHLD в обработчике делает wait | waitpid
которые вычитывают причины завершения процесса из структур ядра.

man 7 signal
Signal Value Action Comment
-------------------------------------------------------------
SIGCHLD 20,17,18 Ign Child stopped or terminated


Обрати внимание, что по умолчанию он игнорируется.

Akh

Не канает:


[quot автор]
Main pid=4072
Child pid=4074
Killed


Издеваешься?
Или лень дочитать до конца?

man 2 wait
In the Linux kernel, a kernel-scheduled thread is not a distinct con-
struct from a process. Instead, a thread is simply a process that is
created using the Linux-unique clone(2) system call; other routines
such as the portable pthread_create(3) call are implemented using
clone(2). Before Linux 2.4, a thread was just a special case of a
process, and as a consequence one thread could not wait on the chil-
dren of another thread, even when the latter belongs to the same
thread group. However, POSIX prescribes such functionality, and since
Linux 2.4 a thread can, and by default will, wait on children of other
threads in the same thread group.

The following Linux-specific options are for use with children created
using clone(2).



з.ы. Сам я это еще не пробовал.

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

AkhВ исходниках ядра по слову "Killed" ничего подходящего не нашел.

Killed пишет шелл из которого запущено приложение.
см. предидущие посты.

A. Fig Lee
а они при чем? Надо в самой программе ловить в хендлере



Имется ввиду что это

Akh


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

з.ы. Но ИМХО поймать конкретное место всеравно будет тяжело.

AkhПроведенные опыты показали, что где бы я не регестрил обработчик на SIGSEGV, он одинаково вызывается:
1) С pid дочернего процесса.
2) wait возвращает ошибку, что нет дочернего процесса.

Поэтому, мне кажется, логично сделать следующие выводы:
1) Обработчик сигнала регистрируется в рамках группы задач. По крайней мере SIGSEGV.
2) Обработчик вызывается при возникновении сигнала в окружении задачи, к которой пришел сигнал. Для всех сигналов.

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

Верно?

Я толькочто глянул сюда

Там написано:

автор
Thread operations include thread creation, termination, synchronization (joins,blocking), scheduling, data management and process interaction.
A thread does not maintain a list of created threads, nor does it know the thread that created it.
All threads within a process share the same address space.
Threads in the same process share:
Process instructions
Most data
open files (descriptors)
[ i]signals and signal handlers
current working directory
User and group id
Each thread has a unique:
Thread ID
set of registers, stack pointer
stack for local variables, return addresses
signal mask
priority
Return value: errno
pthread functions return "0" if OK.

Исходя из этого определить нить которая ведет себя неправильно путем отлова сигналов,
возможно при использовании маскирования сигналов во всех нитях кроме одной
(потенциально проблемной).

Думаю это всеравно тупиковый путь.
ИМХО ловить нужно не нить, а функцию где это происходит.

Akh

Что за маскирование? Не встречал. Какие функции помогут для понимания?


sigaction, sigprocmask, sigpending, sigsuspend - POSIX signal handling functions

Akh
Отловить функцию сложнее, и я даже не предствляю как. Где увереность, что в этот момент другой поток не вызвал критическую ситуацию?


Давай двигаться от простого к сложному и от общего к часному.
Поверь это позволит очень сократить время на отладку кода.


man 2 signal
NOTES
The effects of this call in a multi-threaded process are unspecified.
The routine handler must be very careful, since processing elsewhere
was interrupted at some arbitrary point. POSIX has the concept of
"safe function". If a signal interrupts an unsafe function, and han-
dler calls an unsafe function, then the behavior is undefined. Safe
functions are listed explicitly in the various standards. The POSIX
1003.1-2003 list is
_Exit() _exit() abort() accept() access() aio_error() aio_return()
aio_suspend() alarm() bind() cfgetispeed() cfgetospeed() cfsetispeed()
cfsetospeed() chdir() chmod() chown() clock_gettime() close() con-
nect() creat() dup() dup2() execle() execve() fchmod() fchown()
fcntl() fdatasync() fork() fpathconf() fstat() fsync() ftruncate()
getegid() geteuid() getgid() getgroups() getpeername() getpgrp() get-
pid() getppid() getsockname() getsockopt() getuid() kill() link() lis-
ten() lseek() lstat() mkdir() mkfifo() open() pathconf() pause()
pipe() poll() posix_trace_event() pselect() raise() read() readlink()
recv() recvfrom() recvmsg() rename() rmdir() select() sem_post()
send() sendmsg() sendto() setgid() setpgid() setsid() setsockopt()
setuid() shutdown() sigaction() sigaddset() sigdelset() sigemptyset()
sigfillset() sigismember() signal() sigpause() sigpending()
sigprocmask() sigqueue() sigset() sigsuspend() sleep() socket() socketpair()
stat() symlink() sysconf() tcdrain() tcflow() tcflush() tcgetattr()
tcgetpgrp() tcsendbreak() tcsetattr() tcsetpgrp() time()
timer_getoverrun() timer_gettime() timer_settime() times() umask()
uname() unlink() utime() wait() waitpid() write().

According to POSIX, the behaviour of a process is undefined after it
ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by
the kill(2) or the raise(3) functions. Integer division by zero has
undefined result. On some architectures it will generate a SIGFPE
signal. (Also dividing the most negative integer by -1 may generate
SIGFPE.) Ignoring this signal might lead to an endless loop.


Особое внимание нужно обратить на использование защищенных функций при работе с потоками и строками.

Akh

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

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

Akh onstat- Akh

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

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

Ну, тут уже ничего не поделаешь... Важно, быть уверенным, что упал именно этот.

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

Завести поток арбитража, который сериализует выполнение нитей через мутексы, и ведет протокол очередности выполнения.


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

Если приводит все будет понятно, кто последним запущен тот и виноват.

A. Fig Lee Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

Это трудоемкий процесс - раз.
Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два.

Я хочу знать какой поток совершил глупость. Потом совмещая с мессаджами, определять ошибку.

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

а смысл? если каждый поток исполняет тот же код? что ето даст?

Это даст возможность локализовать проблему,
во взаимодействии нитей ( нити портят данные паралельной записью),
или все же проблема не зависит от нитей ( появляейтся и при последовательном выполнении).

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

onstat- A. Fig Lee Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

Это трудоемкий процесс - раз.
Среди десятка мессаджей (десяток потоков) надо будет искать после которого произошла ошибка. Это два.

Я хочу знать какой поток совершил глупость. Потом совмещая с мессаджами, определять ошибку.

А что вы думаете на счет того, что обработчик вышел с pid-ом, вызвавшего критическую ситуацию, потока?

а смысл? если каждый поток исполняет тот же код? что ето даст?

Это даст возможность локализовать проблему,
во взаимодействии нитей ( нити портят данные паралельной записью),
или все же проблема не зависит от нитей ( появляейтся и при последовательном выполнении).

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

Прошу прощения, не заметил что это ответ не мне.
Устал устал уже видимо за день.

Akh onstat-Это даст возможность локализовать проблему,
во взаимодействии нитей ( нити портят данные паралельной записью),
или все же проблема не зависит от нитей ( появляейтся и при последовательном выполнении).

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

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

Я хотел узнать, какой поток вызывает аварийное завершение приложения.

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


в результате должно получиться приблизительно следующее:


Дальше будем смотреть.

з.ы. Это должно быть первым дествием после того как программа падает во время отладки.