Зависание процессов classic на linux
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
вот собственно:
#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 ()
#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 при мониторинге запросов сталкивался.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 ()
А где видно, что оба вызова блокируют семафор ?v6y писал(а):Интересно. Неужели и здесь двойная блокировка семафора?
server_main вложен в себя 4 раза ?
и isc_unwind_request - 6 раз ? (это верхнеуровневый вызов АПИ вообще-то, т.е. сам движёк его не вызывает никогда)
Трасса левая, увы.
Думаю доверять в ней можно только инф-ции о системных вызовах.
Посему рекомендую скачать debug info и повторить
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
Как обычно - здесь http://sourceforge.net/project/showfile ... up_id=9028
файлы с debuginfo в имени
файлы с debuginfo в имени
Я не утвержлдаю на 100%, но обрати внимание на #6.hvlad писал(а):А где видно, что оба вызова блокируют семафор ?v6y писал(а):Интересно. Неужели и здесь двойная блокировка семафора?
Во время isc_commit_transaction была произведена некая операция с семафором (см #восемь) В это время процесс получает некий сигнал (скорее всего LockSignal из firebird.conf), далее выполняется обработчик сигнала (см #6) в котором вновь производится некая операция с семафором (см #1), что может привести к зависанию при определенных условиях. Как работают семафоры в Линукс знаешь? А то мне немного лениво объяснять.
Я чиать умеюv6y писал(а):Я не утвержлдаю на 100%, но обрати внимание на #6.hvlad писал(а):А где видно, что оба вызова блокируют семафор ?v6y писал(а):Интересно. Неужели и здесь двойная блокировка семафора?
Я ооочень не уверен что во время именно isc_commit_transaction.v6y писал(а):Во время isc_commit_transaction
Если там есть какие-либо платформенные особенности, то достаточно кинуть в меня ссылкой с их описаниемv6y писал(а):была произведена некая операция с семафором (см #восемь) В это время процесс получает некий сигнал (скорее всего LockSignal из firebird.conf), далее выполняется обработчик сигнала (см #6) в котором вновь производится некая операция с семафором (см #1), что может привести к зависанию при определенных условиях. Как работают семафоры в Линукс знаешь? А то мне немного лениво объяснять.
Далее - где видно, один это семафор или разные ?
Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи
Гуща, не гуща но даже из этого трейса можно сделать однозначные выводы:hvlad писал(а): Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи
1) Зависание таки произошло при выполнении isc_commit_transaction - ну не мне же тебе рассказывать, что трасса показывает все НЕЗАВЕРШЕННЫЕ вызовы? isc_commit_transaction, судя по трассе, один из них, причем в первых рядах.
2) Во время системного вызова semop, процессу был послан некий сигнал (LockSignal?) и был вызван обработчик этого сигнала.
3) Из обработчика сигнала вновь был вызван semop и именно этот вызов semop привел к зависанию (опять смотрим трассу) Причем вызов был в рамках одного и того же процесса, с одними и теми же сегментам стека, кода и данных.
Далее уже логически - в каких случаях семафор висит? Например при попытке применения операции -1 к семафору, значение которого равно 0. (при операции +1 семафор не виснет). На что похожа данная ситуация? Именно на то что семафор был заблокирован, затем до того как он был разблокирован, процесс получил сигнал, и из обработчика попытался еще раз блокирнуть тот же семафор, что и привело к зависанию.
Подчеркиваю, я не утверждаю, что было именно так, но ситуация очень на то похожа. По крайней мере, когда я сталкивался с зависаниями при мониторинге в 2.1 именно подобное безобразие имело место быть.
Эта трасса кривая - сказать это ещё N раз ???v6y писал(а):Гуща, не гуща но даже из этого трейса можно сделать однозначные выводы:hvlad писал(а): Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи
1) Зависание таки произошло при выполнении isc_commit_transaction - ну не мне же тебе рассказывать, что трасса показывает все НЕЗАВЕРШЕННЫЕ вызовы? isc_commit_transaction, судя по трассе, один из них, причем в первых рядах
isc_unwind_request не вызывается из isc_commit_transaction
и уже тем более из самой себя
никакие обработчики сигналов не вызывают KEYWORD_getTokens
и уже тем более это не вызывается из gds__alloc
поэтому я не могу делать выводы из этой трассы
поэтому всё вышесказанное именно гадание
что тут не понятного ?
Да все мне понятно. Только у меня тоже кое-какой опыт имеется и потому готов забиться, что самая наипремейшая трасса показалы бы, что имели место:hvlad писал(а):Эта трасса кривая - сказать это ещё N раз ???v6y писал(а):Гуща, не гуща но даже из этого трейса можно сделать однозначные выводы:hvlad писал(а): Но без чёткого понимания что делал движёк это всё не даёт ровно никакой информации - гадание без кофейной гущи
1) Зависание таки произошло при выполнении isc_commit_transaction - ну не мне же тебе рассказывать, что трасса показывает все НЕЗАВЕРШЕННЫЕ вызовы? isc_commit_transaction, судя по трассе, один из них, причем в первых рядах
isc_unwind_request не вызывается из isc_commit_transaction
и уже тем более из самой себя
никакие обработчики сигналов не вызывают KEYWORD_getTokens
и уже тем более это не вызывается из gds__alloc
поэтому я не могу делать выводы из этой трассы
поэтому всё вышесказанное именно гадание
что тут не понятного ?
1) незавершенный вызов isc_commit_transaction
2) получение сигнала и вызова обработчика
3) зависание при вызове semop из обработчика сигнала
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
Даже если и так, то это всё равно не даёт практически ни какой инф-цииv6y писал(а):Да все мне понятно. Только у меня тоже кое-какой опыт имеется и потому готов забиться, что самая наипремейшая трасса показалы бы, что имели место:
1) незавершенный вызов isc_commit_transaction
Это как раз не оспаривается. Но я даже не вижу какой тут сигнал обрабатывается. Соответственно не могу предполагать о каком (каких) семафорах идёт речьv6y писал(а):2) получение сигнала и вызова обработчика
3) зависание при вызове semop из обработчика сигнала
И этот процесс называется - гадание
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
спустя 9 месяцев с начало открытия топика, сервак не висит . все благодаря тому что запущен firebird_debug. конечно это приятно, но вам господа разработчике следует признать что баг все же присутствует в firebirde, и если кому лень перечитывать топик с самого начала то напоминаю что проблем нет ни в одном из вариантов firebirda окромя firebird cs for linux. на мой взгляд проблему устранить будет не так-то и просто, ну во первых надо получить данные из под debug версии firebirda, а оно на нем как раз и работает нормально. так что замкнутый круг .
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
-
- Сообщения: 98
- Зарегистрирован: 27 апр 2006, 09:32
странный ты немного. перечитай топик сначала и обрати внимание кто первый начал переходить на личности и писать гадости в коментах. знаеш я не такой мега крутой програмист как ты но мне приятно что проблема не в моей проге а в твоей криворукости и себялюбии. просто признавать ошибки надо уметь. я конечно понимаю что оно тебе даром не нужно.
и заметь после намека как ты быстро обьявился . ведь по существу проблемы и сказать нечего , да и не устраните вы ее. вот и будут постоянные топики, ой подвисло а чего же делать???:). я понимаю что людям региться сдесь влом, прочитают по быстрому поставят дебаг и забудут про блоки, если бы еще и отписались сдесь что помогло ты бы неприятно удивился сколько людей имеют эту же проблему.
и заметь после намека как ты быстро обьявился . ведь по существу проблемы и сказать нечего , да и не устраните вы ее. вот и будут постоянные топики, ой подвисло а чего же делать???:). я понимаю что людям региться сдесь влом, прочитают по быстрому поставят дебаг и забудут про блоки, если бы еще и отписались сдесь что помогло ты бы неприятно удивился сколько людей имеют эту же проблему.
это домыслы. где эти люди? тут, на sql.ru, на gmane? может еще где?сдесь что помогло ты бы неприятно удивился сколько людей имеют эту же проблему.
И потом, такое впечатление с твоих слов, будто Влад этот баг написал. Ты бы знал, какие неожиданные фишки порой выколупываются из кода Джима! И как раз такого же рода - за фиг знает какое время существования InterBase - всего порядка десяти человек, кто на тот баг напоролся.
Ну и, ты сам же подтвердил, что проблему практически невозможно отловить. Что отвечать-то на такое заключение?