Re: threads

[Vlad Harchev <hvv@hippo.ru>]

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