On Tue, 1 Aug 2000, Alexander Kotelnikov wrote: > On Tue, Aug 01, 2000 at 01:09:27AM +0400, Peter Novodvorsky wrote: > > ++ 01/08/00 01:03 +0400 - Alexander Kotelnikov: > > > Hi, > > > > > > multithreaded программа делает Sefmentation fault, приотладки с gdb > > > выясняется, что она получает "SIGTTOU", я как-то в первые с этим сигналом > > > столкнулся, чтобы это могло значить? У программы две нитки, пишущие в > > > stdout > > > > SIGTTOU Остановка фонового процесса, если он пытается записать данные > > на свой управляющий терминал. > > > > (C) Terrence Chan. > > ну это еще и ``man 7 signal'' впрос почему это возникает. > > Есть некоторое чувство, что "главная" нитка каким-либо образом блокирует > stdout для "побочной". Возникает это чувство из-за того, что программа не > всегда получат Segfault'ы, но достаточно часто, чтобы обеспокоиться. При этом > замечено, что если "главной" нитке увеличить жизнь, добавив sleep(3) в конце, > то все перестает глючить напрочь.
У меня такая гипотеза: SIGTTOU программа получает только когда отлаживается под gdb (так как от SITTOU программы не сегфаултятся и не падают - см. man 7 signal - их просто останавливают). Поэтому, если софтина падает по sefault, значит ошибка происходит в другом месте. Я бы порекомендовал разрешить кидать корки и посмотреть в корке где упала софтина: gdb -c core-file-name или что-то типа того - я не помню (насколько я помню, после запуска gdb таким образом надо набрать where и он скажет где софтина упала). И еще - я чувствую, что программа на С++ - поэтому я бы удостоверился, что либы, которые используются обоими витками, мультинитевые (иначе программа может падать в какой-то либе). Если используется STL, то надо определить какой-то макрос - и т.д. > > -- > Alexander Kotelnikov > Saint-Petersburg, Russia > Best regards, -Vlad
