powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Можно ли узнать из за какого потока было убито приложение?
5 сообщений из 55, страница 3 из 3
Можно ли узнать из за какого потока было убито приложение?
    #34317167
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akh onstat-Дабы приоткрыть дверь в темную комнату, опубликуй пожалуйста здесь
вывод , который появится на экране после выполнения:

Нет сейчас никакого приложения, которое падает. Излечил в течении суток с момента задания вопроса. Сейчас интересует подход/средства по поставленному вопросу.

по этому?

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


Конкрентый ответ дать тяжело.

Если в общем, то ИМХО при разработке модульной архитектуры,
желательно предусмотреть возможность трассировки модулей по отдельности.
И включения трассировки на лету путем посылки(обработки) сигналов (SIGUSR1 например).

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

Таким образом вопросы неоднозначного поведения(трактования задачи)
решаются с постановщиком или самостоятельно
еще на этапе первых запусков программы(модуля).

Где ловить эти исключения, зависит он контекста.
НО самое главное, там будет известно место, откуда оно пришло.
...
Рейтинг: 0 / 0
Можно ли узнать из за какого потока было убито приложение?
    #34317238
A. Fig Lee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akh A. Fig Lee Akh A. Fig Leeбесполезно ето, как онстат говорит. надо месседжи дебаговые в функции вставлять.

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

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

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

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

У меня обычная схема - взаимодействие классов, некоторые из которых имеют свои потоки. Стековая архитектура (по типу TCP/IP). Код выполняется разный, и кто-то (поток) может спороть ерунду. Если опредилить, кто это сделал, будет проще начать искать ошибку (функцию, потом действие, потом анализ ситуации, а потом уже анализ причин).

Не понимаю. Потоки разные, но ходят по одним и тем же функциям или нет. Если да, то нет смысла ловить.

Вообще средствами скриптов не так уж сложно добавить в каждую функцию типа

Код: plaintext
1.
2.
3.
#ifdef DEBUG
  syslog()...
#endif
...
Рейтинг: 0 / 0
Можно ли узнать из за какого потока было убито приложение?
    #34317278
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Резюме к моему последнему посту :

[ b]Поддержка и развитие большого проекта всегда обходится дороже разработки версии 1.0
...
Рейтинг: 0 / 0
Можно ли узнать из за какого потока было убито приложение?
    #34317983
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-Если в общем, то ИМХО при разработке модульной архитектуры,
желательно предусмотреть возможность трассировки модулей по отдельности.
И включения трассировки на лету путем посылки(обработки) сигналов (SIGUSR1 например).

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

Таким образом вопросы неоднозначного поведения(трактования задачи)
решаются с постановщиком или самостоятельно
еще на этапе первых запусков программы(модуля).

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

1. учту. спасибо.
2. Использую. Не всегда хватает. Особенно не зная, какой поток облажался.
...
Рейтинг: 0 / 0
Можно ли узнать из за какого потока было убито приложение?
    #34317996
Akh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
A. Fig Lee Akh
У меня обычная схема - взаимодействие классов, некоторые из которых имеют свои потоки. Стековая архитектура (по типу TCP/IP). Код выполняется разный , и кто-то (поток) может спороть ерунду. Если опредилить, кто это сделал, будет проще начать искать ошибку (функцию, потом действие, потом анализ ситуации, а потом уже анализ причин).

Не понимаю. Потоки разные, но ходят по одним и тем же функциям или нет. Если да, то нет смысла ловить.

Вообще средствами скриптов не так уж сложно добавить в каждую функцию типа

Код: plaintext
1.
2.
3.
#ifdef DEBUG
  syslog()...
#endif


1. Выделил жирным.
2. Была такая мысль, когда-то. Но средствами скриптов отказался. Сейчас использую в ручную.
...
Рейтинг: 0 / 0
5 сообщений из 55, страница 3 из 3
Форумы / C++ [игнор отключен] [закрыт для гостей] / Можно ли узнать из за какого потока было убито приложение?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]