Зависание процессов classic на linux

victor3000 · Сообщение **victor3000** » 21 фев 2007, 20:35

вот собственно:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7bba0eb in semop () from /lib/libc.so.6
#2 0xb7d7dc86 in gds__alloc () from /opt/firebird/lib/libfbembed.so.2
#3 0xb7efe0d5 in KEYWORD_getTokens () from /opt/firebird/lib/libfbembed.so.2
#4 0xb7efe4b1 in KEYWORD_getTokens () from /opt/firebird/lib/libfbembed.so.2
#5 0xb7d7cd41 in gds__alloc () from /opt/firebird/lib/libfbembed.so.2
#6 <signal handler called>
#7 0xffffe410 in __kernel_vsyscall ()
#8 0xb7bba0eb in semop () from /lib/libc.so.6
#9 0xb7d7dc86 in gds__alloc () from /opt/firebird/lib/libfbembed.so.2
#10 0xb7e1a7c7 in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#11 0xb7e19de8 in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#12 0xb7e0f36b in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#13 0xb7e98caa in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#14 0xb7e5c8ec in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#15 0xb7e5449a in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#16 0xb7d85568 in isc_commit_transaction ()
from /opt/firebird/lib/libfbembed.so.2
#17 0xb7f24f95 in server_main () from /opt/firebird/lib/libfbembed.so.2
#18 0xb7f279a4 in server_main () from /opt/firebird/lib/libfbembed.so.2
#19 0xb7f23dbb in server_main () from /opt/firebird/lib/libfbembed.so.2
#20 0xb7f2399d in server_main () from /opt/firebird/lib/libfbembed.so.2
#21 0x08048569 in __libc_start_main ()
#22 0xb7b1087c in __libc_start_main () from /lib/libc.so.6
#23 0x080484b1 in __libc_start_main ()

v6y · Сообщение **v6y** » 21 фев 2007, 21:03

victor3000 писал(а):вот собственно:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7bba0eb in semop () from /lib/libc.so.6
#2 0xb7d7dc86 in gds__alloc () from /opt/firebird/lib/libfbembed.so.2
#3 0xb7efe0d5 in KEYWORD_getTokens () from /opt/firebird/lib/libfbembed.so.2
#4 0xb7efe4b1 in KEYWORD_getTokens () from /opt/firebird/lib/libfbembed.so.2
#5 0xb7d7cd41 in gds__alloc () from /opt/firebird/lib/libfbembed.so.2
#6 <signal handler called>
#7 0xffffe410 in __kernel_vsyscall ()
#8 0xb7bba0eb in semop () from /lib/libc.so.6
#9 0xb7d7dc86 in gds__alloc () from /opt/firebird/lib/libfbembed.so.2
#10 0xb7e1a7c7 in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#11 0xb7e19de8 in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#12 0xb7e0f36b in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#13 0xb7e98caa in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#14 0xb7e5c8ec in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#15 0xb7e5449a in isc_unwind_request () from /opt/firebird/lib/libfbembed.so.2
#16 0xb7d85568 in isc_commit_transaction ()
from /opt/firebird/lib/libfbembed.so.2
#17 0xb7f24f95 in server_main () from /opt/firebird/lib/libfbembed.so.2
#18 0xb7f279a4 in server_main () from /opt/firebird/lib/libfbembed.so.2
#19 0xb7f23dbb in server_main () from /opt/firebird/lib/libfbembed.so.2
#20 0xb7f2399d in server_main () from /opt/firebird/lib/libfbembed.so.2
#21 0x08048569 in __libc_start_main ()
#22 0xb7b1087c in __libc_start_main () from /lib/libc.so.6
#23 0x080484b1 in __libc_start_main ()

Интересно. Неужели и здесь двойная блокировка семафора? Я с похожим только в 2.1 при мониторинге запросов сталкивался.

hvlad · Сообщение **hvlad** » 21 фев 2007, 23:52

v6y писал(а):Интересно. Неужели и здесь двойная блокировка семафора?

А где видно, что оба вызова блокируют семафор ?

server_main вложен в себя 4 раза ?
и isc_unwind_request - 6 раз ? (это верхнеуровневый вызов АПИ вообще-то, т.е. сам движёк его не вызывает никогда)

Трасса левая, увы.
Думаю доверять в ней можно только инф-ции о системных вызовах.

Посему рекомендую скачать debug info и повторить

victor3000 · Сообщение **victor3000** » 22 фев 2007, 00:39

елси можно немного подробней про зверя дебуг инфо, где взять как использовать?

hvlad · Сообщение **hvlad** » 22 фев 2007, 01:10

Как обычно - здесь http://sourceforge.net/project/showfile ... up_id=9028
файлы с debuginfo в имени

v6y · Сообщение **v6y** » 22 фев 2007, 07:00

hvlad писал(а):
v6y писал(а):Интересно. Неужели и здесь двойная блокировка семафора?
А где видно, что оба вызова блокируют семафор ?

Я не утвержлдаю на 100%, но обрати внимание на #6.
Во время isc_commit_transaction была произведена некая операция с семафором (см #восемь) В это время процесс получает некий сигнал (скорее всего LockSignal из firebird.conf), далее выполняется обработчик сигнала (см #6) в котором вновь производится некая операция с семафором (см #1), что может привести к зависанию при определенных условиях. Как работают семафоры в Линукс знаешь? А то мне немного лениво объяснять.

hvlad · Сообщение **hvlad** » 22 фев 2007, 11:18

v6y писал(а):
hvlad писал(а):
v6y писал(а):Интересно. Неужели и здесь двойная блокировка семафора?
А где видно, что оба вызова блокируют семафор ?
Я не утвержлдаю на 100%, но обрати внимание на #6.

Я чиать умею

v6y писал(а):Во время isc_commit_transaction

Я ооочень не уверен что во время именно isc_commit_transaction.

v6y писал(а):была произведена некая операция с семафором (см #восемь) В это время процесс получает некий сигнал (скорее всего LockSignal из firebird.conf), далее выполняется обработчик сигнала (см #6) в котором вновь производится некая операция с семафором (см #1), что может привести к зависанию при определенных условиях. Как работают семафоры в Линукс знаешь? А то мне немного лениво объяснять.

Если там есть какие-либо платформенные особенности, то достаточно кинуть в меня ссылкой с их описанием

Далее - где видно, один это семафор или разные ?

Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи

v6y · Сообщение **v6y** » 22 фев 2007, 13:09

hvlad писал(а): Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи

Гуща, не гуща но даже из этого трейса можно сделать однозначные выводы:
1) Зависание таки произошло при выполнении isc_commit_transaction - ну не мне же тебе рассказывать, что трасса показывает все НЕЗАВЕРШЕННЫЕ вызовы? isc_commit_transaction, судя по трассе, один из них, причем в первых рядах.
2) Во время системного вызова semop, процессу был послан некий сигнал (LockSignal?) и был вызван обработчик этого сигнала.
3) Из обработчика сигнала вновь был вызван semop и именно этот вызов semop привел к зависанию (опять смотрим трассу) Причем вызов был в рамках одного и того же процесса, с одними и теми же сегментам стека, кода и данных.

Далее уже логически - в каких случаях семафор висит? Например при попытке применения операции -1 к семафору, значение которого равно 0. (при операции +1 семафор не виснет). На что похожа данная ситуация? Именно на то что семафор был заблокирован, затем до того как он был разблокирован, процесс получил сигнал, и из обработчика попытался еще раз блокирнуть тот же семафор, что и привело к зависанию.

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

hvlad · Сообщение **hvlad** » 22 фев 2007, 13:21

v6y писал(а):
hvlad писал(а): Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи
Гуща, не гуща но даже из этого трейса можно сделать однозначные выводы:
1) Зависание таки произошло при выполнении isc_commit_transaction - ну не мне же тебе рассказывать, что трасса показывает все НЕЗАВЕРШЕННЫЕ вызовы? isc_commit_transaction, судя по трассе, один из них, причем в первых рядах

Эта трасса кривая - сказать это ещё N раз ???

isc_unwind_request не вызывается из isc_commit_transaction
и уже тем более из самой себя

никакие обработчики сигналов не вызывают KEYWORD_getTokens
и уже тем более это не вызывается из gds__alloc

поэтому я не могу делать выводы из этой трассы
поэтому всё вышесказанное именно гадание

что тут не понятного ?

v6y · Сообщение **v6y** » 22 фев 2007, 13:38

hvlad писал(а):
v6y писал(а):
hvlad писал(а): Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи
Гуща, не гуща но даже из этого трейса можно сделать однозначные выводы:
1) Зависание таки произошло при выполнении isc_commit_transaction - ну не мне же тебе рассказывать, что трасса показывает все НЕЗАВЕРШЕННЫЕ вызовы? isc_commit_transaction, судя по трассе, один из них, причем в первых рядах
Эта трасса кривая - сказать это ещё N раз ???

isc_unwind_request не вызывается из isc_commit_transaction
и уже тем более из самой себя

никакие обработчики сигналов не вызывают KEYWORD_getTokens
и уже тем более это не вызывается из gds__alloc

поэтому я не могу делать выводы из этой трассы
поэтому всё вышесказанное именно гадание

что тут не понятного ?

Да все мне понятно. Только у меня тоже кое-какой опыт имеется и потому готов забиться, что самая наипремейшая трасса показалы бы, что имели место:
1) незавершенный вызов isc_commit_transaction
2) получение сигнала и вызова обработчика
3) зависание при вызове semop из обработчика сигнала

victor3000 · Сообщение **victor3000** » 22 фев 2007, 14:06

давай подождем дебаг инфо , получу и продолжим

hvlad · Сообщение **hvlad** » 22 фев 2007, 16:42

v6y писал(а):Да все мне понятно. Только у меня тоже кое-какой опыт имеется и потому готов забиться, что самая наипремейшая трасса показалы бы, что имели место:
1) незавершенный вызов isc_commit_transaction

Даже если и так, то это всё равно не даёт практически ни какой инф-ции

v6y писал(а):2) получение сигнала и вызова обработчика
3) зависание при вызове semop из обработчика сигнала

Это как раз не оспаривается. Но я даже не вижу какой тут сигнал обрабатывается. Соответственно не могу предполагать о каком (каких) семафорах идёт речь

И этот процесс называется - гадание

victor3000 · Сообщение **victor3000** » 23 фев 2007, 18:33

это конечно интересно, поставил на сервак дебуг(надеюсь что правильно), но уже больше суток не висит ... пока жду.

victor3000 · Сообщение **victor3000** » 25 фев 2007, 16:59

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

. какие мысли?

victor3000 · Сообщение **victor3000** » 25 фев 2007, 22:59

спустя 9 месяцев с начало открытия топика, сервак не висит

. все благодаря тому что запущен firebird_debug. конечно это приятно, но вам господа разработчике следует признать что баг все же присутствует в firebirde, и если кому лень перечитывать топик с самого начала то напоминаю что проблем нет ни в одном из вариантов firebirda окромя firebird cs for linux. на мой взгляд проблему устранить будет не так-то и просто, ну во первых надо получить данные из под debug версии firebirda, а оно на нем как раз и работает нормально. так что замкнутый круг

.

victor3000 · Сообщение **victor3000** » 26 фев 2007, 13:48

Почему тишина это никому не интересно?

victor3000 · Сообщение **victor3000** » 26 фев 2007, 17:29

ГОСПОДА РАЗРАБОТЧИКИ ПРОКОМЕНТИРУЙТЕ ПЛИЗ.
p.s. ну почему надо обязательно писать гадость чтоб выйти на диалог с русским человеком

hvlad · Сообщение **hvlad** » 26 фев 2007, 18:12

victor3000 писал(а):p.s. ну почему надо обязательно писать гадость

Вот поэтому мне лично совершенно не хочется писать тебе что-либо ещё

victor3000 · Сообщение **victor3000** » 26 фев 2007, 22:58

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

. ведь по существу проблемы и сказать нечего

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

Сообщение **kdv** » 26 фев 2007, 23:31

сдесь что помогло ты бы неприятно удивился сколько людей имеют эту же проблему.

это домыслы. где эти люди? тут, на sql.ru, на gmane? может еще где?
И потом, такое впечатление с твоих слов, будто Влад этот баг написал. Ты бы знал, какие неожиданные фишки порой выколупываются из кода Джима! И как раз такого же рода - за фиг знает какое время существования InterBase - всего порядка десяти человек, кто на тот баг напоролся.
Ну и, ты сам же подтвердил, что проблему практически невозможно отловить. Что отвечать-то на такое заключение?