The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"main зависает перед return и не хочет завершаться..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

"main зависает перед return и не хочет завершаться..." 
Сообщение от Aptimist Искать по авторуВ закладки(ok) on 03-Мрт-05, 18:02  (MSK)
Проблема изложена в заголовке темы. Добавлю только, что приложение многопоточное (я бы даже сказал: очень многопоточное), и перед закрытием аккуратно командует потокам "свертайсь", ждёт пока они все не завершаться и только потом пробует сделать "return EXIT_SUCCESS;" из main, но... на этом самом месте она и виснет...
Может, кто сталкивался с такими чудесами... подскажите, кто что может...

P.S.: Говорят чудес не бывает...

  Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "main зависает перед return и не хочет завершаться..." 
Сообщение от Dead Mustdie emailИскать по авторуВ закладки on 04-Мрт-05, 09:25  (MSK)
Не зная в точности даже, на каком языке программа написана
(ну хотя бы C vs C++?) объяснение оным чудесам дать
трудноватенько.

Чего GDB печатает по командочке `info threads` после подвисания?
Для каждого обнаруженного потока весьма интересен `bt`.
Естественно, для получения наилучших результатов код должен
быть скомпилирован с отладочной информацией и без оптимизации :)

Если отладчик по каким-то причинам недоступен либо поглючивает
(и такое мы видали), можно, во-первых, убедиться, что все
потоки закрываются, воткнув печать идентификатора потока
в начале каждой поточной функции, а также перед каждым
вызовом pthread_exit(). Далее следует проверить все "очистные"
процедуры, автоматически срабатывающие при выходе из main(),
а также (для C++) деструкторы созданных в main() объектов.

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "main зависает перед return и не хочет завершаться..." 
Сообщение от Aptimist Искать по авторуВ закладки(ok) on 05-Мрт-05, 10:06  (MSK)
>Не зная в точности даже, на каком языке программа написана
>(ну хотя бы C vs C++?) объяснение оным чудесам дать
>трудноватенько.

Программа написана на C++.

>Чего GDB печатает по командочке `info threads` после подвисания?
>Для каждого обнаруженного потока весьма интересен `bt`.
>Естественно, для получения наилучших результатов код должен
>быть скомпилирован с отладочной информацией и без оптимизации :)

А что такое GDB? (извините мою неосведомлённость...)

>Если отладчик по каким-то причинам недоступен либо поглючивает
>(и такое мы видали),

С отладкой многопоточных приложений... пока не знаком...

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

Потоки закрываются (это было проверено в первую очередь)...

>Далее следует проверить все "очистные"
>процедуры, автоматически срабатывающие при выходе из main(),

Как можно проверить ""очистные" процедуры"?

>а также (для C++) деструкторы созданных в main() объектов.

Деструкторы выполняются...

//---------------------------------------------------------

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

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "main зависает перед return и не хочет завершаться..." 
Сообщение от DeadMustdie emailИскать по авторуВ закладки(??) on 05-Мрт-05, 18:39  (MSK)
>Программа написана на C++.

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

Проведите простеёший эксперимент: перенесите весь код
из main в какой-нибудь main_impl(), а из main()
оный main_impl() вызовите. Нечто вроде

#include <stdio.h>

static int main_impl(int argc, char* argv[])
{
  // Код из прежнего main()
}

int main(int argc, char* argv[])
{
  printf("-- before main_impl()\n"); fflush(stdout);
  int rcode = main_impl(argc, argv);
  printf("-- after main_impl()\n"); fflush(stdout);
  return rcode;
}

Если "after" не печатается, значит, деструктор.
Если печатается и программа виснет уже на 'return rcode',
значит, вся беда в некоем exit handler'е.

>А что такое GDB? (извините мою неосведомлённость...)

Отладчик, вестимо. Работающий под практически любой UNIX-подобной
системой. http://www.gnu.org/software/gdb

>С отладкой многопоточных приложений... пока не знаком...

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

>Потоки закрываются (это было проверено в первую очередь)...

Значит, собственно потоки и ни при чём совсем.

>Как можно проверить ""очистные" процедуры"?

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

;-)

>Деструкторы выполняются...

Выполняются - хорошо, но завершаются ли?

>Может что-то происходит со стеком во время выполнения приложения
>и потому return становиться не возможным?.. Но, к сожалению,
>я ещё не настолько продвинутый программер... и не знаю, что
>может повлиять на стек... тем более функции main...
>Может, чего подскажите...

Может. Сие называется порчей стека; причиной порчи стека обычно
является неправильное обращение с указателями. Обнаружить порчу
стека post factum можно с помощью `bt` в отладчике, собственно
некорректные операции с памятью прилично ловит valgrind
http://valgrind.kde.org/.

Стек функции main() есть стек ведущего потока программы и ничем
особенным среди стеков прочих потоков не выделяется.

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх


Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру